Иногда так не хватает подсказок по ходу выполнения миссии ИТ-проекта – «жми W, чтобы двигаться вперёд». Чтобы хоть как-то помочь тем, кто оказался на месте функционального заказчика (от него очень многое зависит на проекте), мы собрали топ-10 подсказок, которые помогут успешно выполнить миссию под кодовым названием «внедрение автоматизированной системы».
Под функциональным заказчиком (ФЗ) мы понимаем человека или группу людей, которые транслируют основные функциональные требования к ИТ-системе. Если вы попадаете под это описание, или руководите проектами, то статья будет вам полезна и, надеемся, интересна.
Эта статья – «крик души» одного из руководителей проектов нашей компании Digital Design Саши. Саша сделал много хороших и очень хороших проектов, так что мы ему верим и внемлем. Он точно знает, как успешно закрыть проект. Саша поделился алгоритмом с нами, а мы делимся с вами.
Раньше в Digital Design было больше проектов по автоматизации делопроизводства, сейчас вектор сместился в сторону индивидуальных бизнес-процессов. Так накопились истории о проектах по автоматизации аудита, корпоративного управления, hr-процессов, договорного и закупочного документооборота, претензионно-исковой деятельности и даже обработки подозрений на мошенничество в банке.
Мы делаем это всё на родной BPM-платформе Docsvision, но эти рекомендации применимы к автоматизации любого другого процесса с использованием и других платформ.
Чтобы быть во всеоружии и оценить масштаб проекта, нужно собрать исчерпывающую информацию и изучить её:
Осведомлён – значит вооружен. Вот только воевать не надо готовиться. Если война, то считайте, проект уже можно хоронить.
Если РП читают эту статью (а нам бы хотелось в это верить), то им эта фраза уже набила оскомину. Как правило, определением заинтересованных лиц занимаются именно РП.
Но почему мы советуем сделать это функциональному заказчику? Да потому что он гораздо лучше знает, как всё устроено внутри компании, где и как пересекаются интересы коллег.
В учебниках по проектному управлению есть классификация, которая помогает не упустить никого из заинтересованных лиц, – её оставим для РП, а ФЗ, для того чтобы этот список составить, лучше максимально подробно ответить вот на эти вопросы:
Когда проект получит официальный старт (распоряжением, например), важно не забыть оповестить всех этих людей, задекларировать цели проекта, обозначить сроки и представить участников.
Далее по ходу проекта необходимо периодически возвращаться к этому списку и планировать свои действия с учётом интересов перечисленных в нём сторон. По каждому из них нужно понимать, как и когда мы должны их привлечь к проекту, в каком контексте это делать и под каким соусом им подавать информацию.
На стороне заказчика должен быть свой руководитель проекта. Поверьте, РП подрядчика не сможет его полноценно заменить. По крайней мере, сроки точно не будут соблюдены, если всей организацией работ будет заниматься только подрядчик.
РП должен быть именно руководителем проекта, т.е. иметь опыт управления проектами — это уникальная сущность, которую не заменит даже шкаф учебников. И бухгалтер с хорошими организаторскими способностями тут не подойдёт. Если речь идёт об ИТ-проекте, то крайне желательно, что РП заказчика разбирался в ИТ-области. Если это не так — пусть возьмёт себе в команду человека из ИТ-подразделения.
Без этого золотого человека можно сразу увеличивать плановые сроки в четыре раза! Лучше потратить свои силы, время и влияние, чтобы этого человека выделить от проектного офиса (если есть) или найти, нанять любыми другими способами.
А когда найдёте, убедитесь, чтобы он проделал п.1 и п.2.
Рабочая группа – это те, кто будет формулировать требования к системе как функциональные, так и технические.
Определять рабочую группу нужно совместно с РП, опираясь на свой и его списки заинтересованных лиц (см. п.2).
При определении рабочей группы следует руководствоваться правилом, что группа, состоящая из более 10-12 человек, сложно управляется, и согласовать интересы в такой группе будет сложно. (Если KPI – закончить проект до конца текущего года, то 10 – лимит).
В рабочую группу обязательно должны входить (кроме ФЗ и РП):
Кстати, один человек может совмещать несколько функций.
Рабочая группа тоже, как правило, закрепляется приказом (распоряжением).
Вообще, это задача обоих руководителей проекта и во многом является выжимкой документа «Устав проекта», который они готовят на старте проекта.
И вот что хорошо было бы на этой встрече задекларировать:
Цели проекта.
А каких целей мы, собственно говоря, хотим достичь. И совпадают ли заявленные в документации цели проекта с реальной болью, которую мы устраняем? Если в документации написана чепуха (такое бывает), то не надо стесняться говорить подрядчику правду. Он всё поймёт.
Этапы и сроки проекта.
Пусть подрядчик расскажет, что будет происходить на каждом этапе проекта, когда потребуется активное участие рабочей группы, а когда нет, как будут организованы те или иные работы (испытания, например).
Результирующие документы проекта.
И в двух словах, что подразумевает каждый документ и для чего он нужен.
Сроки согласования проектной документации.
Важно чтобы все члены рабочей группы понимали, сколько дней у них есть на формирование замечаний и за какое время подрядчик должен их обработать.
Информирование о проекте.
Как часто и в каком формате будут происходить отчётные встречи, отчёты о ходе проекта? Кто должен быть информирован: только рабочая группа или все сотрудники компании, если проект, например, затрагивает всю организацию. В этом случае можно публиковать новости о ходе проекта в корпоративных СМИ.
Процедура внесения изменений.
Какой порядок информирования участников о запросах на изменения, которые потенциально могут повлиять на сроки, стоимость или содержание проекта, и какие действия нужно предпринять после информирования?
По остальным разделам установочной презентации —соль, перец добавить по вкусу (рабочий график на проекте, каналы коммуникации и т.д.)
При формировании требований всем участникам рабочей группы рекомендуем придерживаться следующих правил:
Долго думали, надо ли декларировать аксиомы….
Надо.
Документы проекта надо изучать! Изучать тщательно и подробно. А ещё проверять, чтобы все участники рабочей группы это делали также тщательно и подробно. И дело даже не в том, что подрядчик такой плохой и может не написать того, что обсуждали (хотя это тоже стоит проверить обязательно), просто будет гораздо хуже, если процесс будет описан неправильно.
Испытания на тестовых данных — это неплохо. Но все самые неприятные несоответствия вылезают, когда в системе работают с реальным кейсом. Да, это трудозатратно, и для этого никогда нет доступных ресурсов, но это крайне увеличивает успешность внедрения.
Пусть сотрудники возьмут реальную задачу и вместе с подрядчиком пройдут по ПиМИ (программа и методика испытаний) с реальным сценарием.
Про синдром отличника слышали? Им следует заболеть, если вы автоматизируете процесс диспетчеризации взлётов и посадок в аэропорту или что-то подобное. В остальных случаях примите как данность, что система не будет готова на 100% к моменту начала эксплуатации.
Да, печально. Да, интеграторов нужно закидать гнилыми помидорами и сказать, что так не должно быть и, вообще, «вы там тестируете систему вашу или как…» (с). Но реальность такова, что выходить в опытно-промышленную эксплуатацию скорее всего вам придётся сырыми. На возражение, что пользователям это не понравится, я скажу, что это произойдёт и с готовой на 100% системой. Чтобы этого не было, надо постепенно готовить пользователей к новой жизни и к стрессу, рассказывая о проекте в корпоративных СМИ, рассылках и т.д.
Поэтому нужно просто набраться смелости и стартовать.
При выполнении проекта нужно помнить, что нельзя охватить всё разом. Сделайте сейчас то, что можно сделать сейчас. Остальное оставьте на развитие системы.
Здесь может зародиться мысль о будущих контрактах, подсаживании на «финансовую иглу» и т.д. Но это не так. Попытка объять необъятное имеет очень высокий риск стать долгостроем, который может не просто сорвать сроки, он может не закончиться вовсе.
После окончания проекта важно провести завершающую встречу, подвести итоги проекта, оценить уровень достижения целей и обсудить дальнейшие планы.
Указанное выше:
Под функциональным заказчиком (ФЗ) мы понимаем человека или группу людей, которые транслируют основные функциональные требования к ИТ-системе. Если вы попадаете под это описание, или руководите проектами, то статья будет вам полезна и, надеемся, интересна.
Эта статья – «крик души» одного из руководителей проектов нашей компании Digital Design Саши. Саша сделал много хороших и очень хороших проектов, так что мы ему верим и внемлем. Он точно знает, как успешно закрыть проект. Саша поделился алгоритмом с нами, а мы делимся с вами.
Раньше в Digital Design было больше проектов по автоматизации делопроизводства, сейчас вектор сместился в сторону индивидуальных бизнес-процессов. Так накопились истории о проектах по автоматизации аудита, корпоративного управления, hr-процессов, договорного и закупочного документооборота, претензионно-исковой деятельности и даже обработки подозрений на мошенничество в банке.
Мы делаем это всё на родной BPM-платформе Docsvision, но эти рекомендации применимы к автоматизации любого другого процесса с использованием и других платформ.
Шаг №1. Собрать информацию
Чтобы быть во всеоружии и оценить масштаб проекта, нужно собрать исчерпывающую информацию и изучить её:
- договор,
- конкурсная документация,
- техническое задание,
- информация о подрядчике,
- сроки проекта,
- какие подразделения/дочерние общества задействованы,
- информация об автоматизируемом бизнес-процессе (как сейчас исполняется, какими регламентами задокументирован, насколько они актуальны),
- текущее состояние автоматизации (если, например, старую систему на новую меняете).
Осведомлён – значит вооружен. Вот только воевать не надо готовиться. Если война, то считайте, проект уже можно хоронить.
Шаг №2. Определить заинтересованных лиц
Если РП читают эту статью (а нам бы хотелось в это верить), то им эта фраза уже набила оскомину. Как правило, определением заинтересованных лиц занимаются именно РП.
Но почему мы советуем сделать это функциональному заказчику? Да потому что он гораздо лучше знает, как всё устроено внутри компании, где и как пересекаются интересы коллег.
В учебниках по проектному управлению есть классификация, которая помогает не упустить никого из заинтересованных лиц, – её оставим для РП, а ФЗ, для того чтобы этот список составить, лучше максимально подробно ответить вот на эти вопросы:
- Кого будет затрагивать проект в ходе выполнения? Кто должен будет пошевелиться? Кому придётся что-то отдать (бюджет, ресурсы, своё время)?
- Кого затронет в ходе промышленной эксплуатации (когда уже все будут использовать систему)? Чья работа изменится после внедрения?
Когда проект получит официальный старт (распоряжением, например), важно не забыть оповестить всех этих людей, задекларировать цели проекта, обозначить сроки и представить участников.
Далее по ходу проекта необходимо периодически возвращаться к этому списку и планировать свои действия с учётом интересов перечисленных в нём сторон. По каждому из них нужно понимать, как и когда мы должны их привлечь к проекту, в каком контексте это делать и под каким соусом им подавать информацию.
Шаг №3. Найти РП
На стороне заказчика должен быть свой руководитель проекта. Поверьте, РП подрядчика не сможет его полноценно заменить. По крайней мере, сроки точно не будут соблюдены, если всей организацией работ будет заниматься только подрядчик.
РП должен быть именно руководителем проекта, т.е. иметь опыт управления проектами — это уникальная сущность, которую не заменит даже шкаф учебников. И бухгалтер с хорошими организаторскими способностями тут не подойдёт. Если речь идёт об ИТ-проекте, то крайне желательно, что РП заказчика разбирался в ИТ-области. Если это не так — пусть возьмёт себе в команду человека из ИТ-подразделения.
Без этого золотого человека можно сразу увеличивать плановые сроки в четыре раза! Лучше потратить свои силы, время и влияние, чтобы этого человека выделить от проектного офиса (если есть) или найти, нанять любыми другими способами.
А когда найдёте, убедитесь, чтобы он проделал п.1 и п.2.
Шаг №4. Определить рабочую группу
Рабочая группа – это те, кто будет формулировать требования к системе как функциональные, так и технические.
Определять рабочую группу нужно совместно с РП, опираясь на свой и его списки заинтересованных лиц (см. п.2).
При определении рабочей группы следует руководствоваться правилом, что группа, состоящая из более 10-12 человек, сложно управляется, и согласовать интересы в такой группе будет сложно. (Если KPI – закончить проект до конца текущего года, то 10 – лимит).
В рабочую группу обязательно должны входить (кроме ФЗ и РП):
- Владелец процесса (если это не ФЗ) – это ключевой фактор успеха. Должен быть человек, который однозначно скажет, что надо, а что нет, который разрешит все противоречивые требования и который может принять решение, что процесс будет изменен после внедрения системы, если потребуется. Как правило, это руководитель подразделения, к которому относится автоматизируемый процесс: директор департамента управления делами, если речь о делопроизводстве; директор по внутреннему аудиту, если речь о проверках финансово-хозяйственной деятельности и т.д.
- Специалисты подразделения, которые будут использовать систему, которые достаточно работают в компании и знают, как устроен автоматизируемый бизнес-процесс, знают, где он отличается от документированных процедур, и какие «лазейки» в нём существуют… Замечательно, если среди них есть те, кто когда-либо ранее работал в такой системе, либо уже участвовал в формировании требований к автоматизированной системе (не обязательно даже аналогичной). Если такие есть — в команду!
- Если автоматизированный процесс выходит за границы организации (например, в будущей системе будут работать представители дочерних обществ), то по описанному в пунктах выше принципу нужно подтягивать представителей сторонних заинтересованных организаций, при этом не забывать о правиле 10-12 участников.
- Безопасники must have! Чем раньше подключить их к проекту, тем лучше.
- Представитель от ИТ потребуется, когда речь пойдёт о выделении мощностей для размещения системы, об организации инфраструктуры, пропускной способности сетей и т.п.
Кстати, один человек может совмещать несколько функций.
Рабочая группа тоже, как правило, закрепляется приказом (распоряжением).
Шаг №5. Участвовать в установочной встрече
Вообще, это задача обоих руководителей проекта и во многом является выжимкой документа «Устав проекта», который они готовят на старте проекта.
И вот что хорошо было бы на этой встрече задекларировать:
Цели проекта.
А каких целей мы, собственно говоря, хотим достичь. И совпадают ли заявленные в документации цели проекта с реальной болью, которую мы устраняем? Если в документации написана чепуха (такое бывает), то не надо стесняться говорить подрядчику правду. Он всё поймёт.
Этапы и сроки проекта.
Пусть подрядчик расскажет, что будет происходить на каждом этапе проекта, когда потребуется активное участие рабочей группы, а когда нет, как будут организованы те или иные работы (испытания, например).
Результирующие документы проекта.
И в двух словах, что подразумевает каждый документ и для чего он нужен.
Сроки согласования проектной документации.
Важно чтобы все члены рабочей группы понимали, сколько дней у них есть на формирование замечаний и за какое время подрядчик должен их обработать.
Информирование о проекте.
Как часто и в каком формате будут происходить отчётные встречи, отчёты о ходе проекта? Кто должен быть информирован: только рабочая группа или все сотрудники компании, если проект, например, затрагивает всю организацию. В этом случае можно публиковать новости о ходе проекта в корпоративных СМИ.
Процедура внесения изменений.
Какой порядок информирования участников о запросах на изменения, которые потенциально могут повлиять на сроки, стоимость или содержание проекта, и какие действия нужно предпринять после информирования?
По остальным разделам установочной презентации —
Шаг №6. Интервьюироваться ответственно
При формировании требований всем участникам рабочей группы рекомендуем придерживаться следующих правил:
Не молчать
Когда во время интервьюирования в голову закрадывается мысль, что в процессе, о котором идёт речь, есть исключение или какой-то малюсенький нюанс, который «вроде не влияет», не надо молчать. Лучше потратить ещё пару минут на изъяснение и дать возможность подрядчику оценить, влияет это или нет.
Быть чутким
Да, да, чутким. Если вдруг возникает сомнение, что подрядчик правильно понял заложенный смысл какого-то предложения, то лучше потратить ещё пару минут на объяснение и удостовериться, что все участники одинаково понимают сказанное.
Проверять полноту документации
При предоставлении регламентов нужно убедиться, что комплект документов, подготовленный к отправке подрядчику, полный. Пусть все члены рабочей группы проверят его целостность. Миллион случаев, когда какой-то регламент забывается и всплывает где-то на предварительных испытаниях.
Вообще, хорошая практика перед стартом проекта и началом интервьюирования перечитывать эти регламенты, чтобы вовремя понять, где они отличаются от реальности или от ожиданий, а затем подсветить эту информацию подрядчику.
Вообще, хорошая практика перед стартом проекта и началом интервьюирования перечитывать эти регламенты, чтобы вовремя понять, где они отличаются от реальности или от ожиданий, а затем подсветить эту информацию подрядчику.
Позволить подрядчику поучаствовать в процессе
Нужно дать подрядчику возможность поучаствовать в рабочей деятельности в рамках автоматизируемого процесса. Пусть он пронаблюдает этот путь — от начала и до завершающей стадии процесса — и вникнет, как это происходит. Но это не заменяет интервьюирования; и лучше даже это сделать после интервью.
Шаг №7. Согласовывать документы тщательно
Долго думали, надо ли декларировать аксиомы….
Надо.
Документы проекта надо изучать! Изучать тщательно и подробно. А ещё проверять, чтобы все участники рабочей группы это делали также тщательно и подробно. И дело даже не в том, что подрядчик такой плохой и может не написать того, что обсуждали (хотя это тоже стоит проверить обязательно), просто будет гораздо хуже, если процесс будет описан неправильно.
Шаг №8. Провести реальные испытания
Испытания на тестовых данных — это неплохо. Но все самые неприятные несоответствия вылезают, когда в системе работают с реальным кейсом. Да, это трудозатратно, и для этого никогда нет доступных ресурсов, но это крайне увеличивает успешность внедрения.
Пусть сотрудники возьмут реальную задачу и вместе с подрядчиком пройдут по ПиМИ (программа и методика испытаний) с реальным сценарием.
Шаг №9. Не бояться выходить в опытно-промышленную эксплуатацию
Про синдром отличника слышали? Им следует заболеть, если вы автоматизируете процесс диспетчеризации взлётов и посадок в аэропорту или что-то подобное. В остальных случаях примите как данность, что система не будет готова на 100% к моменту начала эксплуатации.
Да, печально. Да, интеграторов нужно закидать гнилыми помидорами и сказать, что так не должно быть и, вообще, «вы там тестируете систему вашу или как…» (с). Но реальность такова, что выходить в опытно-промышленную эксплуатацию скорее всего вам придётся сырыми. На возражение, что пользователям это не понравится, я скажу, что это произойдёт и с готовой на 100% системой. Чтобы этого не было, надо постепенно готовить пользователей к новой жизни и к стрессу, рассказывая о проекте в корпоративных СМИ, рассылках и т.д.
Поэтому нужно просто набраться смелости и стартовать.
Шаг №10. Завершить проект красиво
При выполнении проекта нужно помнить, что нельзя охватить всё разом. Сделайте сейчас то, что можно сделать сейчас. Остальное оставьте на развитие системы.
Здесь может зародиться мысль о будущих контрактах, подсаживании на «финансовую иглу» и т.д. Но это не так. Попытка объять необъятное имеет очень высокий риск стать долгостроем, который может не просто сорвать сроки, он может не закончиться вовсе.
После окончания проекта важно провести завершающую встречу, подвести итоги проекта, оценить уровень достижения целей и обсудить дальнейшие планы.
P.S.
Указанное выше:
- Применимо для современных компаний, больших и малых.
- Применимо (как ни странно) при выполнении проектов по ГОСТ 34 и документировании по РД 50.
- Можно совмещать с гибкими методологиями, противоречий нет.
- Является выстраданным на личном опыте, не является полноценным, но обязательно будет дополняться.
- Призвано помочь заказчику лучше понять подрядчика и увеличить шансы на взаимовыгодный успех.
