Продолжая тему особенностей культуры ведения проектов автоматизации и внедрения информационных систем нельзя обойти такое интересное явление как методология. Подумайте, насколько вообще людям свойственно в своей профессиональной деятельности сверяться с какой либо методологией? Но проект — это в первую очередь короткий срок и если быстро не принять хоть какие-то правила, пусть даже не самые идеальные, то ничего просто не выйдет.
«Сказано пацакам в клетке выступать, значит, надо в клетке.»
Само понятие «методология внедрения» неразрывно связано с консалтингом по информационным системам. В конечном итоге именно за это и платят консультантам вне зависимости от их способностей. Казалось бы — как это возможно? А кто же тогда будет работать? Вот как раз кто, над чем и как именно будет работать определяет методология.
Поскольку весь мой опыт в консалтинге связан с внедрением приложений от Oracle, и в частности Oracle Transportation Management, то и рассказ будет о фирменной методологии внедрения готовых приложений, созданной и рекомендованной Oracle. В оригинале это увесистая «библия внедренца» на английском языке и буквально на все случаи проектной жизни. Это кстати очень похоже на американский подход к медицине, когда любую болезнь можно по описанию симптомов найти в авторитетном медицинском справочнике и по этому же справочнику назначить лечение. При этом от инструкций лучше не отклоняться и собственного мнения тоже лучше не иметь. Только так можно сохранять безупречность.
Как вы понимаете, методология американская и известна как AIM (Application Implementation Method), затем была усовершенствована до AIM for Business Flows. Если пока не вдаваться в детали, то в первом случае мы поступательно шли к результату, собирали требования, описывали процессы и впервые как следует знакомились с внедряемой системой только к концу проекта, когда уже бывало поздно исправлять ошибки. Во втором случае подход значительно изменился, стал гораздо ближе к реальной практике внедрения благодаря многократному тестированию системы на различных этапах ее готовности.
Кстати, если говорить о доступном переложении AIM на русский язык, то одно из них принадлежит одному моему бывшему коллеге и замечательному человеку — Олегу Саидову-Лебединскому. Это пособие очень помогло мне быстро освоить суть методологии на реальном проекте и стало поводом гордиться таким знакомством.
Еще позже появилась совершенно всеобъемлющая версия методологии — Oracle Unified Method. Но это скорее не практическое пособие, а в некотором роде полное собрание самых передовых методов и подходов в универсальном виде. И если в предыдущих версиях методологии собственно внедрения и управления проектом внедрения четко разделялись, то OUM включает в себя и то и другое и много еще чего такого, что к практике внедрения напрямую и не относится. Хорошее описание OUM на русском нашла у коллеги-ораклойда.
Поскольку я практик, новшествам не доверяю и всегда успешно работала по AIM for BF, то о ней и будет рассказ. И еще немного о PJM (Project Managment Method) — это методология управления проектами, призванная придать больше организованности всем взаимодействиям в проекте.
Методология — это наше ВСЕ, это гарантия качества, это уверенная позиция, это спасение в конфликте, это первое и последнее средство от любой проблемы. Чтобы понять как работает это чудесное средство для начала нужно всех расставить по местам, вернее по ролям.
«Нет, ты тоже пацак. Ты пацак, ты пацак и он пацак. А я чатланин и они чатлане. Так что ты цак надень и в пепелаце сиди. Ясно?»
После подписания договора на консалтинговые услуги компания в целом и каждый ее сотрудник неожиданно для себя становится Заказчиком. Некоторые первое время даже чувствуют себя неловко, но потом все привыкают к обращению «Уважаемый Заказчик!» и к тому что о них говорят в третьем лице в их же присутствии «это было требование Заказчика» или «эти данные предоставил Заказчик».
Ключевой пользователь — полномочный представитель интересов заказчика на проекте, желательно чтобы таких инициативных пользователей было 2-3 человека, чтобы они могли заменять друг друга и успевать выполнять свою обычную работу. Важно чтобы ключевые пользователи хорошо знали процессы, которые предстоит автоматизировать, и чтобы имели реальную возможность и полномочия при необходимости эти процессы изменять. Именно эти замечательные люди станут настоящими авторами системы, первыми познакомятся с ее возможностями и будут лично тестировать все предлагаемые решения на предмет пригодности.
Самая большая ошибка, которую можно допустить на старте проекта — это назначить ключевых пользователей из числа сотрудников ИТ-службы заказчика, даже если им кажется, что они прекрасно разбираются в основном бизнесе компании. Именно бизнес, а в нашем случае, это логисты, должны быть заказчиками и полноправными хозяевами системы, даже если технически за проект отвечает ИТ-служба. Только так будет заинтересованность, ответственность и все что необходимо для успеха.
А какие роли от консалтинга обычно задействованы и чем им предстоит заниматься:
- Руководитель проекта — составление и регулярная актуализация плана работ, плана управления проектом, организация согласования проектных документов, проведение регламентных встреч.
- Архитектор — разработка функциональной архитектуры решения: точки интеграции, логика обмена, анализ возможных альтернатив настройки и разработки.
- Консультант — полный цикл работ от описания бизнес-процессов и сбора требований до настройки системы, формирования заданий на разработку, разработка сценариев тестирования, проведение системных тестов, конвертация данных.
- Разработчик — разработка расширений стандартной функциональности: интерфейсы интеграции, дополнительная логика в виде хранимых процедур, отчеты и печатные формы.
- Системный администратор — установка всех приложений и баз данных, обновление, управление средствами интеграции, мониторинг работы приложения, базы данных, настройка резервирования, миграция.
Согласно методологии с одной стороны есть понятие «объединенная проектная команда», а с другой стороны существует четкое разделение ответственности между Заказчиком и Исполнителем. Поэтому пока все идет хорошо и по плану, то мы имеем дело с командой, но как только начинаются проблемы — начинается противопоставление и разбор кто и какие свои обязанности выполняет плохо или просто медленно.
Как проектные работы, так и проектные разборки необходимо проводить организовано, в соответствии с утвержденной процедурой и регламентом. А заниматься этим должен специалист.
«Это ПЖ со своим пацаком. Узнают, что не присел — пожизненный эцих с гвоздями.»
Самая незавидная роль на любом проекте достается конечно руководителю проекта или как обычно его называют для краткости — РП. А самый главный документ, в который он заглядывает каждый день и с каждым днем все с меньшим оптимизмом — это План работ.
План работ — это календарный график выполнения проектных задач, который обычно формируют в MS Project в соответствии с согласованными в контракте сроками выполнения проекта. Некоторые задачи выполняются строго последовательно, например, нельзя начать тестировать разработку пока ее не выполнишь, а некоторые удается сделать параллельными, например, пока консультанты заняты настройкой и документированием, разработчики могут заниматься интерфейсами интеграции. Чем больше удается делать параллельно, тем больше шансов успеть в срок. Изначально план формируется всегда с какими-то допущениями, т.к. точно знать все особенности и нюансы заранее невозможно. Отсюда необходимость время от времени уточнять план, чаще всего конечно в сторону увеличения сроков. Чем опытней РП, тем больше допущений он закладывает в план и тем он ближе к реальности.
Дело в том, что в начале пути заказчики еще не осознают нагрузки, которая им предстоит в связи с проектом. Ведь даже собственно приемка результатов, которая является главной обязанностью заказчика, — очень кропотливый и трудоемкий процесс, не говоря уже о необходимости участвовать в интервью, промежуточных тестах и готовить данные для загрузки в систему. Одним словом, как это ни странно, в большинстве случаев несоблюдение сроков связано не с тем, что консультанты не успевают выполнять работу, а с тем что заказчик не успевает ее принимать. А без приемки промежуточных результатов двигаться дальше довольно трудно — вдруг нужно будет что-то переделывать по замечаниям?
Чтобы помочь как можно быстрее и эффективнее наладить проектное взаимодействие РП на начальном этапе готовит специальный документ — План управления проектом. Документ похож на краткое и доступное изложение методологии, а именно тех конкретных ее частей, которые будут применяться в данном проекте. На самом деле в оригинале методология несколько избыточна (настолько, что при большом желании можно документировать буквально каждый шаг каждого члена команды) и задача РП взять из нее ровно те документы и задачи, которых будет достаточно и не перегружать команду лишней бумажной работой.
Важная часть Плана управления проектом — это регламент согласования проектных документов, когда устанавливается последовательность и самое главное — предельные сроки рассмотрения документов. Также должны быть продуманы меры, которые будут приняты при несоблюдении этих сроков. Другой важный вопрос, влияющий на сроки — это функциональные границы проекта, которые обычно стараются прописать заранее и как можно более подробно как в самом контракте, так и в Плане управления проектом. Границы обязательно должны быть — как по срокам, так и по функциональности. Если вдруг в процессе знакомства с системой заказчику понравились дополнительные возможности, которые ранее в границы проекта не входили, или выяснилось, что вместо согласованного объема доработок нужно вдвое больше, то на этот случай в Плане управления проектом обязательно предусмотрена Процедура управления изменениями. Она поможет расставить приоритеты и формализовать оценку увеличения сроков и стоимости проекта при внесении изменений в согласованные границы.
«Я скажу всем, до чего довёл планету этот фигляр ПЖ! Пацаки чатланам на голову сели!»
И последнее о рабочих буднях РП: Риски и спорные вопросы. Проект вообще рискованное и спорное мероприятие и требует постоянных компромиссов в процессе, поэтому я считаю, что всё должно решаться в рабочем порядке. Но если вариантов нет и надо включать административные методы, то регистрируем риск или спорный вопрос, чтобы привлечь внимание к проблеме, побыстрее ее разрешить и двигаться дальше. Суть этого документа — придать какой-то уровень приоритета проблеме (как правило Критический, иначе зачем вообще документ), поставить ее на контроль, описать суть, вероятность негативных последствий и варианты выхода из ситуации. Такой документ с одной стороны очень полезен для заказчика, т.к. помогает принять взвешенное решение, а с другой стороны частично снимает ответственность с исполнителя, что тоже приятно. Кстати, прошу прощения у знатоков-теоретиков за вольное использование термина «проблема», конечно я помню, что проблема — это реализовавшийся риск, а риск может и не случиться вовсе.
Обязательные разделы Плана управления проектом (еще его иногда называют Уставом):
- Границы Проекта
- Цели Проекта
- Подходы и методы
- Задачи Проекта, Результаты и Контрольные Точки Проекта.
- Роли и обязанности участников проекта
- Организацию управления проектными работами
- Процедуры управления рисками и спорными вопросами.
Мне приходилось выполнять роль РП на ОТМ-проектах, но пожалуй авантюрным духом этой профессии я так и не прониклась. Дело в том, что управлять тем, что ты отлично знаешь и делаешь сам и буквально еще двое или трое твоих коллег, очень легко. Легко делать оценки, прогнозы, легко рассказывать о документах, когда пишешь их своей рукой и точно знаешь зачем. Конечно, есть и трудности. Например, трудно абстрагироваться от деталей в нужный момент, но внедрение только ОТМ мало похоже на проекты полномасштабной автоматизации, включающие десятки различных модулей. Здесь совмещение ролей РП и функционального архитектора мне кажется оптимальным вариантом.
— Извините, а гравицаппа — это что?
— Ну, гравицаппа — это то, без чего пепелац может только так летать, а с гравицаппой — в любую точку вселенной — за 5 секунд.
Проект не может существовать без проектной документации, которая и есть материальное воплощение методологии и точного ее соблюдения. На самом деле методология — это и есть набор шаблонов проектных документов и рекомендации в какой последовательности, как и кто должен их заполнять.
В любом варианте методологии проект делится на пять этапов или фаз (названия привожу на русском языке, этот перевод наиболее точно отражает содержание):
- Определение. По завершению данной фазы определяются планы и процедуры управления проектом, проведено обучение проектной команды (CRP 1), декомпозированы границы проекта в терминах цепочек будущих бизнес-процессов, предварительно определена функциональная и техническая архитектура системы, определены стратегии и подходы к тестированию и конвертации данных.
- Анализ операций. По завершению данной фазы будущие бизнес процессы и цепочки бизнес процессов компании зафиксированы и определено, как они будут реализованы с помощью выбранных бизнес-приложений. Так же зафиксированы основные требования к реализации шагов бизнес процессов в системе.
- Уточнение / Проектирование решений. В ходе данной фазы в частности производится настройка прототипа промышленной системы и проводится тестирование на прототипе системы будущих бизнес-процессов по согласованным сценариям. Так же определено, какие бизнес требования не могут быть удовлетворены с помощью стандартной функциональности, и какая дополнительная разработка необходима. Выявленные в результате CRP 2 требования могут впоследствии уточняться и видоизменяться, но появления новых требований на последующих фазах не происходит.
- Построение. По завершению данной фазы все разработки завершены, в ходе данной фазы производится окончательная настройка прототипа промышленной системы, разработаны наиболее критичные для бизнеса расширения и проведено тестирование на прототипе системы расширений и будущих бизнес-процессов в целом по согласованным сценариям (CRP 3), пользовательская документация разработана.
- Переход. В ходе этой фазы проводится обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.
Параллельно тому, как фазы сменяют друг друга, идет итеративное тестирование системы. Тестирование, а вернее среда, в которой оно проходит называется CRP (Conference Room Pilot). Такое название связано с тем, что первый прототип (Pilot) будущей системы согласно методологии AIM for BF появляется в самом начале проекта и постепенно эволюционирует, а на определенных контрольных точках все участники должны собраться, зайти в систему (Conference Room), провести тестирование по бизнес-сценарию и зафиксировать результаты — успешные и не очень.
В норме достаточно трех циклов (вернее контрольных точек), после каждого из которых фиксируются достигнутые результаты и уточняются задачи на следующую фазу.
«Ребят, как же это вы без гравицаппы пепелац выкатываете из гаража? Это непорядок.»
Кстати, при формальной оценке качества внедрения, например, если вы заказываете аудит проекта у авторитетной компании, единственным объективным источником информации о проделанной работе является не столько система, которую настраивали консультанты, сколько проектная документация. Ведь если настройки или даже сама система будут утеряны у Заказчика должен остаться результат, вернее возможность полностью его воспроизвести. Но это самая прикладная и очевидная причина вести документацию. Есть и другие — не менее важные, но менее очевидные, особенно в самом начале пути, когда цельная картина еще не складывается.
Привожу проверенную временем и мной лично подборку проектных документов по фазам. Здесь точно нет ничего лишнего, но совершенно достаточно для качественного решения всех проектных задач. Непонятные латинские буквы и цифры — это дань AIM и принятой в нем кодификации документов, коды могут меняться в зависимости от версии AIM, но суть будет та же.
1 Определение
CR.010.План управления проектом.
WM.020.План работ.
BF.015.Высокоуровневая бизнес модель. Диаграммы процессов верхнего уровня будущей модели в формате MS Power Point. Описание будущей архитектуры, точек интеграции с внешними системами.
2 Анализ операций
BF.020.Бизнес процедуры. Детальное описание шагов исполнения процессов, определение зон ответственности за исполнение процесса по ролям в формате Tutor.
BF.040.1.Каталог расхождений теста. Документ фиксирует отклонения и требования возникшие в результате проведения как локальных так и сквозных тестов.
3 Уточнение / Проектирование решений
BF.160.1.Определение параметров настройки системы.
TE.040.2.Сценарий 2-го сквозного системного теста. Сквозной сценарий 2-го тестирования бизнес-модели на основе детальных бизнес процедур. Включает в себя тестирование проведенных настроек системы согласно выявленным на предыдущей фазе требованиям.
TE.035.Сценарии тестирования. Сценарии тестирования различных возможностей использования системы на конкретных примерах.
BF.040.2.Каталог расхождений теста. Документ фиксирует отклонения и требования возникшие в результате проведения как локальных так и сквозных тестов.
MD.021.Реестр разработок. Перечень расширений, которые будут реализованы в рамках проекта, сформированный на основе Каталога расхождений после CRP2. Перечень предполагает расстановку приоритетов для расширений, согласно которым будет выстроена очередность разработки.
4 Построение
MD.050.Функциональный дизайн расширения. Документ описывает требования бизнеса к разработке. Для отчетов определяется состав информации, внешний вид, параметры отбора информации и ограничения доступа. Для форм и интерфейсов — порядок и механизм обработки, внешний вид. Для параллельных программ — алгоритм работы.
MD.070.Технический дизайн расширения. Документ описывает технические подробности создания расширения. Указываются источники данных для разработки отчета, алгоритмы обработки.
TE.040.3.Сценарий 3-го сквозного системного теста. Сквозной сценарий 3-го тестирования бизнес-модели на основе детальных бизнес процедур. Включает в себя также сквозное тестирование расширений и интерфейсов с внешними системами.
BF.170.1.Определение уровней доступа. Детальное описание пользовательских меню для различных полномочий, особенностей персональных настроек.
TE.110.Протокол тестирования системы. Документ, подготовленный на основе сценариев тестирования и содержащий результаты прохождения шагов тестов и выявленные недостатки.
5 Переход
BF.160.1.Определение параметров настройки системы. Завершение настройки системы и документирование финальных настроек.
BF.170.2.Определение уровней доступа. Завершение настройки полномочий и ролей и документирование финальных настроек.
DO.070.Инструкции пользователя. Инструкции создаются на основе BF.020.Бизнес процедур.
CV.040.Определение данных и правил конвертации. Приложениями идут файлы с данными.
AP.150.Пособие для обучения конечных пользователей. Учебные материалы для проведения обучения конечных пользователей, презентации по различным темам, «памятки».
Наконец, ведение проектных документов — это исполнительская дисциплина и достоверный источник информации о деятельности консультантов.
«Плюк — чатланская планета, поэтому мы, пацаки, должны цаки носить.»
И еще несколько слов о дисциплине. Поскольку время консультанта — это в прямом смысле слова деньги, то как правило даже на проектах, которые делаются за фиксированную стоимость, принято заполнять так называемые ежедневные «тайм-шиты» (time sheet) или табель использования рабочего времени. Относиться к этому можно по-разному, но совершенно точно такие табели создают у РП и Заказчика иллюзию контроля над происходящим, а у консультантов — ощущение повинности.
Лично я всегда заполняла табели при работе на проектах и поэтому могу дать объективную оценку этой деятельности. Ничего общего с реальной картиной рабочего дня табель не имеет и как правило просто представляет собой перечень проектных документов, в которые за целый день вносились изменения в процессе работы. Еще встречаются такие фразы: «проведение консультаций», «сбор требований», «участие в совещании рабочей группы», «тестирование». Одним словом — отписались и хорошо. Ведь и без того работы хватает, тем более что работаем не по часам, а на результат и порой далеко в нерабочее время.
Когда нужен табель? Когда вы нанимаете консультанта на работу по часам и оплачиваете эту работу соответственно. В этом случае табель должен представлять собой «фотографию рабочего дня». Еще табели необходимы в крупных проектах, когда внедряется много различных модулей, но проектом в целом управляет один РП, который в дела каждого модуля особенно не вникает, но должен отмечать прогресс по общему плану работ. В таком случае бывает достаточно еженедельного отчета, из которого будет виден процент выполнения по текущим задачам плана, возможные риски и имеющиеся проблемы.
Если внедряется один модуль и дополнения к нему, то РП должен быть достаточно погружен в текущую работу и находиться в постоянном тесном контакте с рабочей группой, чтобы не отвлекать консультантов на формальную отчетность. Ведь владеть ситуацией — это значит предугадывать отставание от плана и заранее принимать меры, а не узнавать о нем по факту из табеля или того хуже — от Заказчика.
— Дядя Вова, цапу надо крутить, цапу!
— На, сам делай!
— Нельзя. Я чатланин.
— Уйди отсюда! Как советовать, так все чатлане, как работать, так…
Поскольку есть разделение команды на Заказчика и Исполнителя, то у первого может сложиться впечатление, что работать на проекте ему не придется и результат ему принесут в конце перевязанный алой лентой. А это самая главная ошибка и верный путь к провалу. Если вы хотите поучаствовать в действительно успешном проекте, то придется потрудиться и не меньше своего подрядчика. И дело тут не в том, что все консультанты лентяи и бездари, дело в том, что ваша главная задача в проекте — это перенять знания и опыт, досконально изучить предлагаемые консультантами решения, протестировать на реальных примерах и данных, убедиться в том, что все работает как надо. Это огромный труд и ответственность, особенно если раньше вы такого опыта не имели.
Не нужно успокаивать себя тем, что «вот все подрядчики уйдут, все уляжется и мы спокойно и размеренно примемся осваивать решение, которое они нам оставили». Когда все уйдут будет поздно и вы поймете, что это все не то, что вас обманули и не поняли.
Цель проекта внедрения — не просто настроить систему, а передать знания и сформировать на стороне заказчика полноценный центр компетенций, который будет в силах не только поддерживать, но и развивать решение. Система без людей, которые могут уверенно в ней работать, ничего не стоит. Добросовестный консультант никогда не оставит проект в беспомощном состоянии, чтобы потом еще долго-долго продаваться по часам. Хорошим, востребованным консультантам это не может быть выгодно — они обычно заканчивают один проект и сразу идут внедрять другой. Застревать на прежних проектах значит упускать новые внедрения, новый интересный опыт и терять навык проектной работы, превращаясь в банальную службу поддержки, которая только и делает, что повторяет ответы на одни и те же вопросы.
Включайтесь сразу — это главный совет. Это ваша система с самого начала поэтому ведите себя как хозяин: вникайте в детали, узнавайте как все устроено, пробуйте все делать своей рукой. Только так вложенные деньги окупятся с лихвой.
Нет, генацвале! Когда у общества нет цветовой дифференциации штанов, то нет цели. А когда нет цели…
На каком-то этапе проекта, когда сроки будут срываться, а вокруг будет ужасная неразбериха, могут возникнуть мысли: «А зачем вообще этот ворох документов? Зачем все усложнять соблюдая регламенты, процедуры, этапность? К чему многократные уточнения требований когда и так уже все понятно?» Так вот помните, что это малодушие и не сдавайтесь. Вы же строите высококлассную автоматизированную систему, чтобы ваш бизнес мог выйти на новый уровень, а не довольствовался Excel и электронной почтой. Это не может быть просто. И именно потому что это очень сложно, ни в коем случае нельзя отказываться от проверенной методологии.
— Это твое заднее слово?
— Заднее не бывает.
Добро пожаловать на борт!