Проектные риски. Практика

From Galaktikaerp

Оглавление - Проектные риски

Contents 1 Риски на стадии подготовке к автоматизации 1.1 Риск при выборе системы 1.2 Риск при выборе консалтинговой компании 1.3 Риск неготовности компании к проведению автоматизации 2 Риски на стадии обследования 3 Риски на стадии внедрения 3.1 Риск значительных доработок 3.2 Риск разрушения команды 3.3 Риск недостаточной функциональности системы 4 Риски на стадии поддержки 4.1 Риск разрушения команды

Риски на стадии подготовке к автоматизации

Риск при выборе системы

Рекомендации по выбору системы автоматизации я изложил тут.

Риск некорректного выбора системы автоматизации не настолько велик, как кажется.

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

Вариантов ошибки здесь два:

1. Выбирается система с чрезвычайно /излишне/ широким функционалом.

   В ходе внедрения такой спектр возможностей не востребован.

   Заказчик вынужден переплачивать за невостребованный им функционал.

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

   Возникает соблазн реализовать ВСЕ бизнес-процессы компании (или абсолютный максимум их) в рамках такой системы. Что зачастую неэффективно.

   Такие системы обычно дороже.

2. Выбирается система с чрезвычайно узким функционалом.

   В ходе внедрения возникает ощутимая нехватка возможностей системы.

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

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

Системы с ограниченным функционалом обычно относятся к классу специализированных или узкоспециализированных, которые обычно более эффективны в областях своей специализации.

Стоит так же отметить, что ряд полнофункциональных систем можно внедрять по отдельным модулям, что снижает риск переплаты за излишний функционал. К таким системам относится Галактика и MBS.

Если система является конструктором (яркий пример - 1С), то недостающий функционал можно доработать, при этом резко увеличив риск потери команды и риск неподдерживаемости системы.

Способы минимизации:

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

Риск при выборе консалтинговой компании

Консалтинговая компания может:

1. не обладать необходимым в работе опытом - вы же не хотите быть пробным проектом для данной компании

   Лучшей рекомендацией для потенциального консультанта является наличие успешных проектов по вашему профилю по выбранной системе. Хотя все должны с чего-то начинать. Если для заказчика превалирует ценовой фактор (то есть )

2. не обладать необходимыми для выполнения проекта ресурсами - количество персонала консалтинговой компании и/или степень его загруженности могут не позволять выполнять проект высокими темпами.
3. не обладать необходимой для успешного завершения работ стабильностью - компания-консультат может просто не дожить до завершения работ по вашему проекту и развалиться. Бывает и такое.
4. быть излишне большой или слишком маленькой для вашего проекта. Не стоит поручать работы по проекту с бюджетом порядка 20000 у.е. специалистам крупной консалтинговой фирмы. Этого бюджета хватит на десяток страниц не очень подробного отчета об обследовании бизнес-процессов компании-заказчика. Но и несколькомиллионный проект не стоит передавать на реализацию компании из трех человек. По понятным причинам.

Между консультантами и заказчиками должны установиться ПАРТНЕРСКИЕ отношения. Ведь цель проведения работ у той и другой стороны одна - построение работающей автоматизированной системы. Поменять консультанта в ходе работ практически нереально, поскольку большой объем важной информации о функционировании компании заказчика, о деталях настройки системы автоматизации существует лишь в головах консультантов и (в лучшем случае) во внутренней документации компании-исполнителя. Если консультант сменится, всю эту информацию необходимо будет собирать, а возможно и создавать заново. Построив систему накопления знаний можно снизить риск смены консультантов и риск распада команды.

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

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

ИТАК

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

Риск неготовности компании к проведению автоматизации

• Ведется ли на предприятии компьтеризированный учет движения материальных ценностей?

• Имеются ли в бухгалтерском учете актуальные и точные данные по движению МЦ?

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

Без положительного ответа на такие банальные вопросы начинать работы по проекту автоматизации не стоит.

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

• Планируются ли организационные изменения в компании, которые повлияют на ход работ по проекту?

• Нет ли в компании проблем с управляемостью? Насколько полно, качественно и своевременно выполняются руководящие решения?

• Достаточно ли у компании человеческих (руководящих и исполнительских) ресурсов для успешного хода работ?

• Достаточно ли у компании финансовых ресурсов для успешного хода работ.

• Есть ли готовность у руководства компании идти на значительные затраты ресурсов? Финансовых и человеческих.

Риски на стадии обследования

Риск на стадии обследования один - некачественное обследование.

Все зависит от качества консультантов.

С учетом того, что результат обследования - ТЗ или проект внедрения подвержен - изменению на более поздних стадиях работ, считаю, что основная ценность обследования - дать команде внедрения - консультантов или/и внутренней понятие об объекте автоматизации. Далеко не факт, что все описание объекта будет формализовано и изложено в виде ТЗ. Но полученное представление о характере бизнес-процессов предприятия для консультантов неоценимо.

Ошибки во время обследования могут быть исправлены на более поздних стадиях работ. ТЗ, созданное в ходе обследования, может претерпевать значительные изменения в ходе внедрения системы. Реальные требования пользователей могут не найти полного отражения в ТЗ, требования к системе автоматизации могут измениться в ходе выполнения проекта в силу изменений, произошедших с объектом автоматизации.

Все это кстати, снижает ценность ТЗ как документа и источника информации.

Риски на стадии внедрения

Риск значительных доработок

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

Для снижения/уменьшения критичности необходимо вносить в стандартный функционал системы автоматизации как можно меньше изменений или дополнений. ЛЮБЫЕ изменения системы не должны затрагивать ее ядро - ее логику построения.

Риск разрушения команды

Появляется и приобретает критичность в связи:

1. с ростом объема доработок, вносимых в стандарный функционал системы;
2. приобретением IT персонала компании опыта во внедрении системы, что приводит к повышению требований работников к оплате своего труда;
3. с отказом от использования сторонних консультантов и передачей все полноты обязанностей по работам внутреннему персоналу компании.

Для минимизации данного риска необходимо сокращать объем доработок стандартного функционала системы автоматизации, поддерживать отношения со сторонними консультантами. И больше платить своим работникам. Все это зачастую трудно сделать - пользователи требуют как можно более удобной и информативной системы, что приводит к росту доработок. Сторонние консультанты стоят денег. И значительных. Платить им обычно приходится некоторую абонентскую плату в ожидании случая, когда услуги консультантов могут пригодиться. Немногие предприятия готовы поддерживать такие отношения со сторонними консультантами. Платить хорошую зарплату собственному персоналу компании также зачастую не готовы - по мнению владельцев, работники IT службы не приносят денег в компанию, они их только проедают. Все это приводит к тому, что из IT службы компании уходят люди. В первую очередь - наиболее ценные.

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

Риск недостаточной функциональности системы

Зависит от соответствия выбранной системы автоматизации масштабу и особенностям бизнес-процессов вашего предприятия.

В случае системы-конструктора будет большой соблазн решить все недостатки по функционалу путем доработки собственными силами или силами консультантов. Что увеличит риск неподдерживаемости системы и риск распада команды.

Риски на стадии поддержки

Риск разрушения команды

Смотрите выше...