Загрузка

ИТ-проекты. От технологии к практике. Часть 1


«Люди не противятся изменениям. 
Они противятся тому, чтобы их изменяли.»
Питер Сенге

Проектное управление – тема модная, раскрученная и таинственная одновременно. Как так получается, что при наличии огромного числа учебных и популярных изданий по этой теме, наличия почти 100% охвата бизнес-сообщества опытом внедрения ИТ-проектов, примеров успешного внедрения не очень много? При этом понятие «успешное внедрение» трактуется очень по-разному Заказчиком и Исполнителем. 

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

Итак, с чего начнем наш проект? С вопроса! И с самого начала я предлагаю изменить парадигму самого первого вопроса на проекте с обычного (для большинства встречаемых мной компаний-Заказчиков) – «Что будем делать на проекте?» на «Зачем будем делать проект?». И ответы типа: «Чтобы внедрить бюджетирование», или «Чтобы внедрить учет материалов» - это в корне неверные ответы! Именно с таких вот ответов начинаются неуспешные проекты, в которых Исполнитель наработался, формально все сделано, подписано, и тихо умерло. Правильный ответ на «Зачем…?» звучит так: «Хотим избавиться от отрицательных остатков на складе; Хотим управлять себестоимостью объекта строительства; Хотим, чтобы при внесении изменений в конструкторскую документацию цех получал эту информацию во-время, ДО того, как приступили к изготовлению изделия…» и т.д.  

Шаг 1: Составить «Проблемное поле».  В методологии PMI это называется «Матрица ТЗС», или Матрица Требований Заинтересованных Сторон. 

Большое количество проблем не должно вас сбивать с толку, у вас нет необходимости под каждую проблему делать Проект, да это и невозможно. Проект вам нужен не для устранения проблем, а для устранения ПРИЧИН возникновения проблем! Сперва, будет полезно сопоставить между собой все перечисленные проблемы, сгруппировать  их, и  выявить несколько КОРНЕВЫХ ПРИЧИН, которые явились источниками проблем. Например, проблема «Отрицательные остатки на складе». Считаю неверным указывать причину этого «Кладовщик не своевременно заводит приходы». Причину надо искать глубже, надо понять ПОЧЕМУ он так делает? У него нет возможности? У него нет необходимых навыков? У него нет мотивации? Существует очень хорошая методология по поиску корневых причин, изложенная Элияху Голдраттом (Теория ограничений, ТОС). 

Шаг 2: Выявить корневые причины. Как я вижу из нашего проектного опыта, корневые причины обычно таятся на стыке функциональных областей управления. Например, проблема с учетом и системой мотивации одновременно. Мы не наладили учет, поскольку никто на это не замотивирован. А также, мы не можем позволить себе объективную систему мотивации, поскольку у нас нет реальных данных учета по отдельным подразделениям, цехам, сотрудникам. Особенность корневых причин состоит как раз в том, что они создают «замкнутый круг». Вырваться из него достаточно сложно. Как бы ни казалось, что это рутинная работа и сами с ней справитесь, настоятельно рекомендую пригласить для выполнения такого анализа консультантов, которым вы доверяете. Взгляд со стороны, мнения опытных внедренцев очень важны на этой стадии. Если неправильно диагностированы корневые причины, то проект явно не поможет  их решить, это значит, что неуспешность проекта будет предопределена! 

А дальше важно понять с помощью каких инструментов (ИТ-программ) и технологий вы можете решить перечисленные проблемы? И здесь ваши консультанты должны трансформировать Матрицу ТЗС в Таблицу «Анализ матрицы ТЗС», где вы увидите проблемы, сгруппированные по Корневым причинам, а рядом наименование ИТ-проекта, который может исправить ситуацию.

Шаг 3: Формализовать необходимые проекты. Расставить приоритеты. Проектов может оказаться несколько. Одновременно вести несколько проектов изменений в компании тяжело. Мало того, как показывает наш опыт, погоня за скоростью (давайте все запараллелим!) может обернуться ситуацией, когда нет сил и ресурсов на ведение и завершение открытых проектов. Поэтому лучше начинать с какого-то одного проекта. Как расставлять приоритеты? Я часто слышу такое мнение от руководителей: «Давайте сделаем пилотный проект вот в таком-то подразделении, у них все более-менее нормально, поэтому на них потренируемся.» Считаю, что это  неверная постановка задачи. Раз в этом подразделении все «более-менее нормально», то и проблемы решаться не будут. Их в этом подразделении просто не было! У меня есть два критерия для выбора пилотного проекта: первый – делать в первую очередь проект с самыми большими проблемами (Там, где много и часто теряем время и деньги. Желательно эти параметры до проекта замерить, чтобы потом была возможность сравнить); второй – делать в первую очередь проект с самым активным и лояльным к изменениям Куратором проекта от Заказчика. Второй критерий более практичный. Почему? Ничто так не вредит изменениям в компании, как опыт неуспешных проектов. 

И только теперь нужно выбирать программный продукт и компанию-внедренца! Большинство же знакомых мне Заказчиков делают с точностью до наоборот. Это усложняет получение успешного проекта. 

Шаг 4: выбор программного продукта и компании-внедренца. Поскольку мы живем в эпоху рыночных отношений, то реализация вашего проекта скорей всего возможна как на различных ИТ-платформах, так и с помощью различных компаний внедренцев. Как не ошибиться в выборе? Вы – Заказчик, вы рискуете деньгами. Исполнитель – тоже рискует! Абсолютно также! Поэтому и вам и ему важно удостовериться, что Программный продукт отвечает вашим требованиям. Вышлите ему список проблем, пусть на встрече вам расскажет и приведет примеры как эти проблемы решались. Выбирая программный продукт не отвлекайтесь от главного: вам нужно не ПО установить на сервере и подключить необходимое количество лицензий, а решить Бизнес-задачи! Поэтому внедренец должен понимать методологию, уметь писать регламенты, инструкции для пользователей, обучать пользователей. Не постесняйтесь спросить отзывы. 

Шаг 5: планирование проекта. «Зачем нам план проекта? Проект нужно делать, а не тратить время на какое-то там планирование», - это очень ошибочные мысли. Мало того, компания-внедренец, которая пренебрегает планированием, скорей всего пренебрегает и качеством. 

Проект – это всегда прыжок в неизвестность. Проектов одинаковых не существует. Для того, чтобы снизить риски, попросите предполагаемого Исполнителя разбить проект на этапы, рассказать вам как вы сможете контролировать результаты этапов, как сможете контролировать качество. Еще раз обращаю ваше внимание на Цель проекта: «Решить Бизнес-задачу», поэтому и контроль должен быть соответствующий: «Я в регламенте увижу   процедуры учета? Кто, или что заставит сотрудников их выполнять?  Как я проверю настройки в программном продукте? Как я пойму, что сотрудники обучены и готовы работать в системе? Как будет выполняться запуск?». Все эти вопросы сводятся в документ «План управления качеством на проекте».

Не менее важным является договоренность между Исполнителем и Заказчиком на тему: «А если что-то пойдет не по плану?». К ситуации «не по плану» можно и нужно подготовиться и тогда она не станет для вас форс-мажором. Для этого нам пригодится «План управления рисками».В нем Заказчик и Исполнитель честно перечисляют «грабли», на которые каждый из них наступал когда-то во время  выполнения проектов.  Но, самое важное прописать в этом же документе взаимоприемлемые способы решения этих конфликтных ситуаций. Поверьте, без них проект не возможен! Договоренности заранее позволяют снизить проблемность проекта на порядок. А значит увеличить гарантии выполнения его в срок. Самым большим камнем преткновения в последнее время для нас являются такие риски, как «Изменчивость мнения Заказчика» и «Появление дополнительных требований по ходу выполнения проекта». Мы с огромным уважением относимся к желанию Заказчика улучшить проект, но бывает, что такие улучшения убивают саму возможность проект завершить. Задайте себе вопрос: Что важнее получить хороший результат в оговоренные проектом сроки, или добиваться превосходного результата когда-нибудь в неопределенном будущем?  В технологии PMIперечислено гораздо большее количество планов управления проектом. Я же здесь рекомендую только те, без которых мы сами сейчас не работаем. Конечно это составленный в диаграмме Ганта «Календарный график выполнения проекта»,с перечнем не только проектных работ, но и результатов, передаваемых Заказчику, совещаний по обсуждению/принятию этих результатов. Понятный для Заказчика Календарный план – основа доверительных отношений, а доверительные отношения, укрепляемые своевременным и качественно сдаваемым промежуточным результатом – залог успешного проекта.

Шаг 6: разработка методологии. Как же не любят руководители подразделений тратить свое время на чтение таких нудных опусов, как: «Управленческая учетная политика», «Регламент Бизнес-процесса «Прохождение заявки на материалы», «Регламент бюджетного планирования»…! Без методологии никак. Если вдруг ваш внедренец не готов предоставить вам такую услугу, стоит  проявить инициативу и настоять, чтобы в составе команды методолог все-таки появился. Дополнительная стоимость участия методолога в проекте окупается сполна. 

Шаг 7: автоматизация. Рутина, которую можно просто пропустить. Кроме единственного, но важного пожелания: не стремитесь перекроить программный продукт под себя. Массовые изменения и доработки превращают ваше ПО в уникальное изделие. Все, что уникально – дорого. Его сложно и дорого обновлять (иногда даже не возможно), его сложно и дорого поддерживать.   Попросите ваших внедренцев показать вам как решается ваша задача в типовом функционале, потратьте время на то, чтобы согласовать минимальные изменения.

Шаг 8: запуск в эксплуатацию. А вот в этом месте проекта и начинается самое интересное! На рынке широко известно выражение «не взлетела». Все сделали правильно: и планировали, и регламент писали-согласовывали, и программу-то настроили в точном соответствии с регламентом… НО люди в системе не работают… по причине… 

Недавно посещала очередную конференцию 1С. Проблема «недовнедренных» проектов в кулуарах энергично обсуждалась. Создалось даже впечатление, что причины не связаны с отдельными личностями, или компаниями, а характеризуют общее состояние бизнес-среды на сегодняшний день.  Из нашего проектного опыта я сделала вывод, что на этом этапе проект как бы раздваивается: с одной стороны, выполняются технологические работы: разработка инструкций пользователей, обучение пользователей, … с другой стороны происходит совершенно не очевидный процесс «принятия», или «отторжения»  проекта пользователями. Бытует мнение, что со времен Макиавелли, с  точки зрения управления людьми, никто не придумал ничего нового: КНУТ и ПРЯНИК. Только формат этого в нашем веке другой. Издать приказ о наказании нарушителей, выписать премию дисциплинированно выполняющим новые требования процесса… Бывает, что помогает.. Наши пользователи – самые продвинутые пользователи! У них есть убийственный аргумент на тему: «Почему не работаете в системе?» и он звучит так: «А кто строить  будет?  А когда я текучкой заниматься (материалы принимать)  буду? У меня срочный заказ, я его сейчас остановить должен?...»  Конечно же, это не является истинной причиной из-за чего сотрудники игнорируют работу в системе, но на практике становится непреодолимым барьером для изменений.

Что же должны сделать команда внедренцев и команда заинтересованных лиц Заказчика, чтобы проект «полетел»? Ответ на этот вопрос я нашла неожиданно для себя не в своде правил проектного управления PMI, а в совершенно иных технологиях управления, например в методологии  IMO (Институт развития человека и организации, Нидерланды). Об этом – в следующей статье. Успешных проектов! 

Вернуться