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