Как заказчик может ускорить автоматизацию своей компании

Многие заказчики уверены, что сроки ИТ-проекта – зона ответственности подрядчика. Но зачастую основная причина, по которой проекты затягиваются или терпят крах, – отсутствие четких договоренностей между заказчиком и подрядчиком. А это уже совместная зона ответственности.

Как сильно могут замедлить автоматизацию бизнеса плохо проговоренные цели, границы, способы реализации проектов? По оценкам экспертов нашей компании 1С-КПД, задержка может составить от 10% до 100% и более по сравнению с закрепленным в договоре сроком.

Хорошая новость: заказчик может на это повлиять. Поделюсь подробностями на примере автоматизации документооборота, которой мы занимаемся.

Вот четыре узловые точки, в которых заказчик и подрядчик могут синхронизировать свое видение проекта и тем самым повлиять на его сроки.

Часто предпосылки для торможения или провала проекта закладываются еще до его старта – когда заказчик выставляет закупочную документацию на конкурс по выбору поставщика ПО.

Во-первых, многие заказчики закладывают в конкурсную документацию задачи, которые на самом деле их бизнесу не нужны.

Пример: заказчик включил в список требований по внедрению 1С:Документооборота задачу автоматизации товароучета. Хотя 1С:ДО в принципе не предназначен для учета товаров. Да, с большими усилиями его можно приспособить к решению этой задачи, но лишь в сильно урезанном виде. При этом в экосистеме 1С есть решения, гораздо больше подходящие для товароучета по своему функционалу.

Однако конкурсные требования победителю конкурса придется выполнять. В итоге часть времени и ресурсов заказчик потратит впустую.

Во-вторых, конкурсные документы часто грешат расплывчатыми формулировками.

Пример: расхожая фраза «Система должна позволять…» Казалось бы, что в ней плохого? Плохо, что любая фраза, допускающая двойное-тройное толкование, размывает границы проекта.

Например, подрядчик может вложить немало человеко-часов, чтобы система позволяла открыть новое окно, нажать кнопку, отработать определенную задачу и зафиксировать результат. А позже выяснится, что заказчик хотел чего-то иного: чтобы задача решалась без открытия нового окна, а кнопок было две, причем, зеленого, а не синего цвета. Работу приходится переделывать.

Заказчиков вполне можно понять. Согласно законодательству о закупках для коммерческих компаний, подрядчик не обязан выполнять то, что не прописано в закупочной документации. Вот заказчики и стараются вложить в нее побольше задач, чтобы избежать проведения дополнительного конкурса. И применяют обтекаемые формулировки, чтобы гибко корректировать требования при изменении обстоятельств.

Но в итоге эффективность автоматизации снижается. А ничем не ограниченный поток требований по доработке системы постоянно сдвигает его сроки и раздувает бюджет.

Что можно посоветовать заказчикам?

Недостатки закупочной документации могут быть исправлены в техническом задании, которое составляется по итогам проектирования системы автоматизации. Но важны две вещи.

Тогда проблема будет снята. Если же этого не сделать, несовершенная закупочная документация останется главным документом проекта со всеми вытекающими последствиями.

Нередко конкурсные требования заказчиков ограничиваются автоматизацией текущих бизнес-процессов. Но когда подрядчик начинает общаться в компании с владельцами конкретных процессов, становится понятно: часть процессов вначале нужно перестроить, и лишь затем автоматизировать.

Пример: все заявки на оплату, создаваемые во всех подразделениях компании, проходят один и тот же маршрут. В итоге финансовому директору приходится заниматься и счетами на десятки миллионов рублей, и буквально копеечными платежами. Хотя понятно, что счет на канцелярские принадлежности не стоит времени, которое на него потратит финдиректор.

Также очевидно, что процесс в таком виде нет смысла автоматизировать. Вначале нужно разработать отдельный маршрут для каждого вида платежей. Например, по одним платежам окончательные решения будет принимать бюджетный комитет, а по другим – руководители профильных департаментов или отделов в рамках своего бюджета. При этом придется разработать новые цепочки движения документов, определить порядок действий сотрудников, предложить критерии их эффективности, внести коррективы в бюджетную политику и т.д.

Проблема в том, что подобная задача требует вовлечения в проект опытных бизнес-аналитиков, немалого количества дополнительных человеко-часов и увеличения бюджета ИТ-проекта.

В подобной ситуации могу порекомендовать заказчикам:

Для успешной работы над проектом нужен еще один документ – его устав. Вот почему без него не обойтись.

Владельцы бизнес-процессов, они же функциональные заказчики, они же топ-менеджеры или руководители подразделений компании – обычно очень занятые люди. В ходе проекта подрядчику бывает очень непросто получить от них требования и обратную связь. А потом многие из них приходят на приемо-сдаточные испытания, смотрят на демонстрацию функционала и говорят: «Нет, это никуда не годится. Нужно все переделывать». И упрекают представителей подрядчика: «А где ж вы раньше были?» И проект заходит на новый круг.

Поэтому важно, чтобы заказчик и подрядчик с самого начала определили уровень вовлечения в проект владельцев процессов и их представителей. Вовлекаемые сотрудники должны заранее знать, когда потребуется их участие. Этот график должен быть четко прописан в уставе проекта.

Например, 20 числа с представителями подрядчика встречается главный бухгалтер. 22, 24 числа – бухгалтер по зарплате, а 25-го – подрядчик демонстрирует ему промежуточные результаты проекта. 2, 4 и 5 числа цикл повторяется с бухгалтером по налогам и т.д.

Устав проекта не относится к закрывающим документам, поэтому не все заказчики (особенно малые и средние предприятия) понимают его ценность. Но он реально способен «закрыть» большинство потенциальных проблем во взаимодействии сторон.

Например, в уставе проекта можно договориться, что все онлайн-коммуникации по проекту проводятся не где придется (в почте, по телефону, в Zoom, Skype и т.д.), а в неком едином месте. Например, в телеграм-канале проекта. И вся переписка в этом канале считается официальной. Благодаря этому документы, предложения, претензии, идеи не будут теряться и качество коммуникаций вырастет.

Устав проекта касается не только коммуникаций, но и проекта в целом. Он увеличивает его эффективность и повышает шансы на успешное завершение.

Подытожу: при запуске проекта важно внимательно поработать над четырьмя документами. Так, чтоб в них не оставалось места для двоякого толкования. Причем два из них, устав проекта и список процессов для перепроектирования, возможно, придется создать впервые в своей практике. Эта работа может показаться времязатратной на старте. Но в итоге она сэкономит многие недели, а возможно, и месяцы в ходе проекта.