Неочевидное добро или управление клиентом в проекте автоматизации
У вас возникла потребность в автоматизации, вы ее осознали, выбрали подрядчика, выделили бюджет, заплатили исполнителю.
С какой стати теперь исполнитель будет управлять вами — пусть лучше свою работу работает. А что если без управления Заказчиком со стороны исполнителя вероятность успешного проекта существенно снизится? Мы ведь хотим, чтобы система была запущена в эксплуатацию. Давайте разберемся
Проект — это совместная работа двух сторон
Иногда мы сталкиваемся с ожиданием клиента, что он заплатит подрядчику деньги, после чего спустя заданный срок просто получит систему. В последнее время такой подход встречается всё реже, но он до сих пор не «вымер» окончательно.
Давайте разберем, почему проект — это большая и плотная работа Заказчика и Исполнителя?
«Обследование бизнес-процессов»
В начале проекта Заказчик предоставляет информацию о своем предприятии — его структуре, сотрудниках, принятых методах работы и подходах, специфике процессов и организации труда.
В зависимости от того, как построено обследование у данного конкретного подрядчика-автоматизатора, эта информация может быть получена и систематизирована по-разному.
Но в любом случае будет необходимо организовать встречи с пользователями (сделать так, чтобы они пришли, и чтобы они честно отвечали на заданные вопросы). Нужно будет предоставить много информации о компании — начиная от регламентирующих документов, заканчивая доступами в информационные системы. Затем, получив от исполнителя документацию, ее нужно прочитать. Нужно сделать так, чтобы ключевые пользователи, руководители подразделений, все заинтересованные лица, прочитали документы внимательно, дали обратную связь.
Причем все эти шаги четко ограничены во времени — особенно если проект в целом должен завершиться к конкретной дате.
Получилось, что на этапе «Обследование» заказчику необходимо выполнить много задач. А если эти задачи не будут сделаны? Можно ли создать подходящую для компании учетную систему и внедрить ее, если процессы, которые будут проходить в системе, не поняты руководителями подразделений, не утверждены ими? Создать систему можно. Но будет ли она «подходящей»? Скорее всего нет.
«Моделирование или контрольный пример»
После обследования начинаются следующие этапы проекта. Выбранный подрядчик, в зависимости от принятой технологии, будет каким-то образом показывать вам, как будут проходить процессы бизнеса в учетных системах, предполагаемых к внедрению. Будет описывать необходимые разработки и настройки. Можете ли вы, как Заказчик, не участвовать в этом?
«Реализация, разработка»
А далее, когда исполнитель будет реализовать разработки, делать интерфейсы и автоматизированные рабочие места, рисовать макеты отчетов и печатных форм. Можете ли вы, как заказчик, не участвовать в приемке? Не смотреть промежуточные результаты?
Можете, и тогда на выходе вы получите что-то неожиданное.
Чем меньше заказчик участвует в проекте, чем меньше он погружен в совместную работу, тем больше будет разбег между его ожиданиями от системы управления, и реальной системой, созданной исполнителем.
Почему клиентом нужно управлять?
Итак, мы вместе разобрались, почему проект — это совместная работа двух сторон. У Заказчика в проекте много задач, организационных и не только. И если Заказчик не будет делать свои задачи, или будет относиться к ним халатно, делать некачественно или дольше, чем по плану, весь проект пострадает. Пострадавший проект может или растянуться во времени, или быть не подходящего качества — система готова, но это совсем не то, чего ожидал клиент и что ему было нужно.
Теперь давайте поговорим о том, как же добиться гладкого, запланированного движения проекта по плану?
Что нужно делать, чтобы исполнители своевременно делали свои задачи? Ответ очевиден — нужно ставить задачи четко, фиксировать ожидаемый срок и нужный результат, и контролировать выполнение задач, корректируя действия исполнителей, если они делают не то, не так, или вообще не приступали и отвлеклись на другие задачи.
Часть работы руководителя проекта — сделать так, чтобы все задачи всех исполнителей были сделаны своевременно и качественно. Из множества выполненных задач в итоге соберется результат, готовая к запуску на предприятии информационная система.
Своими сотрудниками — аналитиками, программистами, консультантами, управляет конечно Руководитель проекта со стороны подрядчика.
Но как мы выяснили ранее, у Заказчика есть множество его задач, и, если он не сделает их правильно и вовремя, вероятность успеха проекта ничтожно мала.
Сотрудниками Заказчика нужно так же управлять в ходе проекта: ставить перед ними задачи, объяснять ожидаемый результат и сроки, и требовать качественного выполнения работы, как и сотрудниками исполнителя.
Кто же должен это делать?
Как много проектов автоматизации, внедрения информационных систем проходит обычное предприятие: малый или средний бизнес? Раз в 5, может в 10, лет происходит внедрение какой-нибудь системы. Между этими внедрениями ключевые сотрудники компании могли покинуть ее, так что даже их опыта «как оно все было», в компании возможно уже не осталось.
Как много проектов автоматизации управления и учета делает компания подрядчик?
Десятки. В Кораде, мы делаем от 20 до 40 проектов разного масштаба в год, на протяжении последних 10 лет. Из них 3-5 проектов достаточно крупных, с сотнями пользователей.
С опытом и практикой приходит знание, понимание того какие действия в проекте сегодня могут его ускорить или погубить через несколько месяцев. Мы знаем, почему пользователи сопротивляются, как понять, что документы не читали, а «подписали, не глядя», знаем, какие риски в данной конкретной компании могут повлиять на сроки. Понимаем, где «соломки подложить» перед запуском. Это опыт практикующего хирурга по сравнению с опытом человека, который однажды порезался, но промыл рану, приклеил пластырь и отделался легким испугом.
Так кто же должен управлять Заказчиком в ходе проекта автоматизации? Профессиональный исполнитель.
Эволюция управления Заказчиком
Давно, когда у нас появились первые проекты и первые требовательные клиенты, мы ввели практику статус-отчетов и статус-встреч.
Это, можно сказать, гигиенический минимум. Регулярный отчет (у нас еженедельный) фиксированного формата содержит информацию о том, что сделано за прошедший период, какие задачи выполнены, а какие просрочены. Если задачи не выполнены — то каковы причины и какие новые сроки.
Так же статус содержит план задач на следующую неделю, в том числе задачи Заказчика, описание текущей ситуации, как ее видит РП с нашей стороны. Информация о выполненных и запланированных задачах у нас собирается из учетной системы (Корадиум). А РП наполняет отчет смыслом, добавляя свое видение ситуации.
Так же раз в неделю мы всегда проводили статус-встречу, на которой РП с нашей стороны встречается с РП со стороны клиента, и другими участниками рабочей группы. РП поясняет статус, обсуждает продвижение, акцентирует внимание участников на «горящих» вопросах.
Если статус-отчетов и встреч в проекте нет, контакт между исполнителем и заказчиком, можно сказать, на нулевом уровне. Управление заказчиком отсутствует.
Время шло, мы разбирали удачные и неудачные проекты. Спустя некоторое время мы поняли, что такого уровня контакта с клиентом недостаточно.
Например, в результате моделирования получается модель и контрольный пример. Это база 1С и достаточно объемный документ, который заказчику необходимо прочитать, посмотреть, понять и утвердить — мол да, это мои процессы, мне все понятно, нравится.
А он физически не может проработать такой объем информации. Ему сложно заставить своих сотрудников прочитать документы, получить с них обратную связь, обработать ее, организовать внутри себя какие-то встречи обсуждения. У клиента нет такой практики, организованной работы в группах. Простые (на наш взгляд) шаги, задачи заказчика, растягиваются на недели и месяцы.
А статус-встречи? А на статус-встречах мы еженедельно обсуждаем важность этой работы, делаем «ай-ай-ай», заказчик посыпает голову пеплом, но не отдает документ.
Теоретически можно сказать: ну что ж, этап задержан из-за клиента, проект растянулся по вине клиента, какие к нам претензии? Но ведь мы заинтересованы дойти до конца, и запустить систему в согласованный срок. Даже если для этого нужно всеми управлять.
Что делать?
Итак, регулярные статус-отчеты и статус-встречи — это минимум проектного взаимодействия, без которого вообще исполнитель не управляет своим клиентом. Но этого мало, нужно больше, еще больше управления.
Мы перестроили свою технологию выполнения проектов так, чтобы еще усилить контакт между подрядчиком и заказчиком.
Как мы управляем клиентом теперь
Наш проект состоит из следующих этапов:
- Обследование бизнес-процессов.
- Моделирование, включая разработку НСИ и ФТ.
- Реализация (настройки, доработки, интеграции).
- Внедрение (обучение, запуск).
- Опытная эксплуатация.
Сейчас не буду останавливаться подробно на каждом этапе, у нас есть про наши проектные технологии видео и дорожная карта. Сегодня мы говорим о том, что добавить в управление заказчиком на каждом этапе, чтобы контакт между сторонами стало больше.
1.На этапе обследования
Можно сказать, что это самый «веселый» этап. Много встреч, интервью, рисование картинок (процессов), споры проектной группы о том, как на самом деле должны проходить те или иные процессы. Много записанных улучшений и изменений. На этом этапе много встреч и общения, как правило здесь контакт достаточно плотный.
2.На этапе моделирования
Для того чтобы повысить «управляемость» — мы разбили работу над моделью на множество отдельных моделей. Мы делаем модели и требования на доработки по каждому блоку и проходим их с клиентом вместе. Далее рабочая группа заказчика «по горячим следам» читает документ, где зафиксирована пройденная модель процессов, и утверждает его.
Мы же в это время готовим моделирование следующего блока процессов. Таким образом вместо одной большой модели, которую надо прочитать и утвердить, при том что некоторые ее части были пройдены в самом начале этапа 1.5-2 месяца назад, мы имеем много итераций, спринтов, на каждом из которых есть наши задачи и задачи клиента.
Если клиент не успевает, мы можем даже притормозить работу надо моделированием следующего блока, чтобы не копить «незавершенную» работу, не принятую, не понятую до конца.
3.На этапе реализации
Когда все ФТ (функциональные требования) согласованы, настройки понятны и интеграции описаны — очень большой соблазн разойтись в стороны месяца на 2-3, «отдохнуть друг от друга». У Заказчика накопились свои дела, а исполнитель может углубиться в программирование, загрузку данных и подготовку системы к запуску.
Как показывает практика — это очень опасно. Уставший клиент за 3 месяца может потерять драйв, задор и интерес к проекту. А подрядчик за это же время может создать систему, которая совершенно не похожа на клиентские ожидания. Даже несмотря на согласованную модель.
Решение — конечно же спринтовая реализация. Мы продолжаем «мучить» заказчика ради общего успеха. Каждую неделю проводим демо выполненных настроек и сделанных доработок, отдаем тестовую базу, и требуем обратную связь по предыдущим спринтам.
Таким образом мы минимизируем риск выпустить продукт, не подходящий, не ожидаемый клиентом.
4.Внедрение
Ну что ж, обучение и внедрение новой системы — это самый плотный контакт. Можно сказать, боевое столкновение. На этом этапе сложно не общаться друг с другом. К сожалению, при неверной организации работы в ходе проекта — это первый плотный контакт подрядчика с клиентом после нескольких месяцев тишины и ощущения «все идет по плану».
Итоги
Итак, друзья, подведем краткие итоги.
- Проект — это большая совместная работа двух сторон, Заказчика и Исполнителя. Обе стороны важны, обе могут спасти или «запороть» общую работу.
- На проект нужно выделить время и внимание (не только деньги). Заплатить деньги и спокойно ждать свою идеальную учетную систему — утопия.
- Правильный подрядчик — готов управлять и собой, и заказчиком. Он понимает необходимость управления клиентом, и обладает инструментами для этого управления.
- Если подрядчик вами управляет — не сопротивляйтесь, он хочет довести проект до успеха. Раз вы доверили ему свой бюджет, доверьте ему и задачи.
Можно ли успешно запустить проект, если исполнитель не умеет управлять проектами? Конечно. Если Заказчик — умеет. Если на стороне клиента сильный проектный менеджер с достаточным влиянием внутри организации, и опытом ИТ-проектов, он может добиться успеха, используя подрядчика как «группу программистов, консультантов и внедренцев».
Успешных вам проектов и безболезненных внедрений.