Добрый день.
Меня зовут Михаил.
Имея многолетний опыт реализации проектов по внедрению различных систем автоматизации (и документооборота в частности), я часто сталкиваюсь с тем, что неподготовленность компании к проекту внедрения на самом начальном этапе влечет за собой значительные трудности в его реализации.
Хочу поделиться своими наблюдениями и дать несколько рекомендаций тем, кто планирует внедрять системы документооборота.
Я мог бы дать ряд рекомендаций компаниям-интеграторам, но сегодня остановлюсь на другом: на что следует обратить особое внимание ИТ-специалисту заказчика.
Раннее выявление слабых мест (несмотря на их кажущуюся очевидность) поможет вам избежать сложностей в дальнейшей реализации проекта.
Приведу ряд случаев из собственной практики (возможно, некоторые читатели узнают себя в примерах – но все совпадения случайны!)
1. «Автоматизируйте все для нас»
Очень часто владелец или высшее руководство ставит перед ИТ-директорами компаний задачу в виде «хочу электронный документооборот».Отмечу, что такая постановка задачи вполне правильна, поскольку руководство компании имеет право ставить любые задачи, а решать их должны подчиненные.
Почему руководство этого хочет, зачастую вообще не говорится.
Может быть, они увидели это у своих деловых партнеров, а может быть, им действительно надоело работать с бумажными документами.
В любом случае, это факт, что первоначальная задача очень часто возникает на эмоциональной почве.
Я рекомендую: старайтесь выявить и решить именно те ключевые задачи, которые будут ценны для бизнеса, не пытайтесь «автоматизировать все» сразу, что, скорее всего, утопично.
Предоставить руководству пошаговый план реализации проекта с обязательным обозначением конкретных ощутимых (возможно, измеримых) промежуточных результатов.
2. «Мы не знаем, как правильно организовать документооборот»
Многие считают, что система документооборота будет действовать как волшебник и сама организует все процессы.Это ошибочное мнение, поскольку система — лишь одно из средств упорядочения и оптимизации процессов.
Чтобы что-то оптимизировать, сначала должен существовать сам процесс.
Прежде чем приступить к проекту по внедрению системы электронного документооборота, необходимо убедиться в том, что этот самый процесс готов к автоматизации.
Вполне логично ожидать, что консультанты по внедрению будут использовать свой опыт в организации бизнес-процессов, но нужно понимать, что это отдельная деятельность, как правило, выходящая за рамки самого проекта.
Я рекомендую: привлечь специалистов для предпроектного обследования компании.
Его результатом станут, как минимум, предложения по организации модели процесса, которая будет отвечать задачам бизнеса и пригодна для дальнейшей автоматизации.
К началу обследования вовсе не обязательно выбирать ту или иную СЭД; требования к нему могут возникнуть по итогам этого нулевого этапа.
3. «Реализуйте, у меня есть час»
В одной из организаций (с численностью более 1000 сотрудников) мы решили последовать предыдущему совету и начать с обследования документооборота.ИТ-директор, с которым я имел честь побывать у специалистов, осторожно постучался в каждый кабинет и с виноватым видом просил сотрудников выделить хоть немного времени для предметного разговора.
В половине кабинетов его просто вежливо (а иногда и не очень вежливо) просили уйти и не отвлекаться.
Ситуация, совершенно не располагающая к нормальной работе.
Я рекомендую: если вы являетесь ИТ-специалистом, ответственным за проект на данном этапе, постарайтесь получить официальное разрешение руководства компании на проведение подобных работ в рабочее время, заранее уведомите сотрудников (приказом или просто письмом).
Казалось бы, мелочь, но все поймут, что происходит, а вы сэкономите время и силы.
4. «Давайте разберемся, что делать на проекте, они же профессионалы!»
Как говорил Наполеон, «On s’engage et puis on voit», то есть «ввяжемся, а там посмотрим».Куда вмешался г-н Бонапарт и что он там увидел, хорошо известно.
Многие проекты провалились из-за того, что на момент их старта ни одна из сторон не понимала, что будет делать в его рамках.
Ведь очевидно, что без понимания сути проекта невозможно его грамотно оценить и спланировать.
Вполне вероятно, что вы как заказчик выскажете требования, которые подрядчик просто не сможет выполнить в рамках заранее определенного бюджета и сроков.
И все будут недовольны.
Я рекомендую: Реализация проекта внедрения ОиД возможна на основе рамочных соглашений, но практика показывает, что даже в этом случае каждый «эпизод» должен быть четко определен в своей функциональной части.
5. «ВАУ, можно переставлять колонки!»
Однажды я проводил тренинг для топ-менеджеров одного из крупных российских заводов (масштаб: более 5000 сотрудников).Серьезные мужчины на час отдохнули от основной работы.
Естественное волнение перед показом системы такой аудитории внезапно исчезло, когда Самый Главный в этой организации с искренним восхищением начал менять графы в презентациях на документах.
Удивительно, но все его верхние коллеги были вдохновлены, и впоследствии подозрительное отношение к проекту сменилось его активной поддержкой.
Я рекомендую: получить поддержку от высшего руководства.
Тогда, поверьте, энтузиазм всей компании в поддержке и освоении новой системы вырастет. 6. «Все будет так, как я сказал» Однажды я делал проект в одной довольно бюрократической организации (около 500 пользователей).
Проект шел в штатном режиме, была проведена опытная эксплуатация, никаких признаков проблем не наблюдалось.
Неожиданно на одной из встреч нас познакомили с человеком, который со стороны заказчика наконец-то примет работу.
Внимательно просмотрев на следующий день презентацию нашей системы, уважаемый представитель заказчика был немногословен - он вручил нам темно-бордовую книгу под своим авторством под названием «Инструкция по офисной работе в компании Х» и сказал, что система должна работать так, как она есть.
там написано, и больше ничего.
Сказать, что команда проекта была в шоке, значит ничего не сказать.
На самом деле проект завершился по чистой случайности (а именно, благодаря переводу указанного коллеги на другую работу).
Я рекомендую: не столько ИТ-директору, сколько руководителю организации: если вы хотите, чтобы проект был успешным, не следует вводить в него новых деятелей, особенно на завершающих этапах, даже если они имеют колоссальный опыт в предметной области.
7. «Директор сам будет создавать документы в системе»
Почти в половине случаев на предпроектных встречах представители заказчика говорят, что руководство их компаний обязательно будет работать в системе, создавать документы, давать инструкции и т. д. Ключевой ошибкой здесь может быть то, что вся система будет спроектирована исходя из того, что менеджеры фактически полностью работают в системе.Часто оказывается, что менеджеры просто не успевают выполнять все запланированные для них функции.
Я рекомендую: подготовьте описание конкретных случаев использования системы вашим руководителем с выбором конкретных способов работы с ней и получите подтверждение от руководителя.
8. «Однако за время путешествия собака могла вырасти!»
Всем участникам проекта, конечно же, хотелось бы, чтобы требования к функциональности создаваемой системы электронного документооборота остались неизменными.Но чудес не бывает, и даже при самой качественной предпроектной экспертизе неизбежно возникнут моменты, о которых все скажут: «мы и не предполагали, что такое может произойти».
В моей практике был даже случай, когда в ходе проекта автоматизируемое подразделение просто ликвидировали.
Но сейчас я уже понимаю, что автоматизировать нужно не подразделения, а бизнес-процессы.
Я рекомендую: Сформируйте среди своей команды понимание того, что изменения — это нормальная ситуация, на которую нужно правильно реагировать, находя взаимоприемлемое решение.
9. «Это совсем не так! Откуда ты это взял?
Как правило, в рамках проекта предусмотрено обучение пользователей.Зачастую многие пользователи впервые узнают о внедрении новой системы непосредственно во время обучения.
Понятно, что большинство стажеров не входили в проектную команду на стороне заказчика, а, следовательно, не участвовали в процессе формирования требований.
Здесь ключевая роль отведена менеджеру проекта на стороне заказчика.
Бывали случаи, когда я оказывался один перед недоумевающей аудиторией, и возникающие дискуссии превращали обучение в очередную неконструктивную дискуссию о функциональном содержании системы.
Я рекомендую: Будет хорошо, если ИТ-специалист компании-заказчика правильно настроит и подготовит студентов к обучению, расскажет, почему система была сделана именно так, а не иначе, каков был порядок принятия тех или иных проектных решений.
10. «Не вмешивайся, он тебя убьет!»
Конечно, для проекта ценно мнение всех сотрудников, но степень возможного участия в проекте не всегда совпадает с его потребностями.Бывает, что конкретные менеджеры среднего звена принципиально отказываются говорить о какой-либо автоматизации своих сотрудников, несмотря на прямые указания высшего руководства.
Тут нужно проявить мудрость – не хотят, то не надо.
Гораздо выгоднее отобрать в команду проекта несколько заинтересованных в результате людей, чем отбирать всех, кто может (даже теоретически) принести ему пользу.
Собственно, именно это и произошло в одном проекте.
Один из дивизионов пришлось полностью исключить из схемы автоматизации.
После окончания проекта от них остался только один вопрос: «А мы?!»
Я рекомендую: Еще на этапе формирования проектной команды на стороне заказчика важно правильно подобрать ее состав.
Конечно, рекомендаций может быть гораздо больше, но для начала я выделил наиболее распространенные ситуации, которые сильно влияют на проект и его результаты.
Если вам нужна консультация по организации грамотной подготовки проекта реализации ЗиД, вы знаете, к кому обращаться! Теги: #СЭД #внедрение СЭД #автоматизация документооборота #ИТ-проект #ECM/СЭД
-
Актуальность Обучения A+
19 Oct, 24 -
Тапири
19 Oct, 24 -
Adsense: Сколько Можно Заработать?
19 Oct, 24