Чего бы пожелать Заказчику?

Конечно, успехов, процветания, здоровья и счастья. Но статья не об этом. Она о том, чего уважаемым Заказчикам стоит хотеть и требовать в отношении внедрения информационных систем (в частности ОТМ), а чего лучше остерегаться желать. Ведь желания могут исполниться, но предполагаемого положительного эффекта не принести или даже напротив могут нанести вполне ощутимый вред.

82190466_81448460

Не гонялся бы ты, поп, за дешевизной!

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

К первым я всегда испытывала уважение за ясность взглядов, а вторые обречены на неопределенность и уклончивые ответы, проверить которые все равно не получится. Правда зачастую никто и не собирается проверять, поскольку это все нужно только на этапе «продажи» проекта менеджменту для соблюдения формальностей. Но нельзя отрицать, что четкое понимание заказчиком целей проекта и правильная расстановка приоритетов, безусловно положительно влияют на конечный результат.

Но что же с обещанной экономией? Чтобы действительно подтвердить потенциальный экономический эффект нужно повести серьезное обследование, выявить реальные, присущие этому конкретному бизнесу области оптимизации/экономии, разработать ключевые показатели, которые будут сопоставимы до/после и подлежат объективному измерению, провести некоторое моделирование в системе или без нее. Самое интересное, что подобные исследования — это профиль консалтинговых компаний, которые собственно внедрением как правило не занимаются, а специализируются на управленческом или бизнес консалтинге, который позиционируется как высший пилотаж и стоит немалых денег сам по себе.

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

Нужен мне работник: 

Повар, конюх и плотник. 

А где найти мне такого 

Служителя не слишком дорогого?

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

Но главное, о чем надо не забыть в суете подготовки увесистой тендерной документации, — это собственно требования к проектной команде, к квалификации и опыту тех работников, которые будут непосредственно трудиться на вашем проекте. В случае ОТМ последнее слово всегда за узкими специалистами. Широкий профиль и универсальные солдаты не для такого проекта, если конечно вы не располагаете лишним временем. Узкий специалист — это тот, кто хорошо делает что-то очень конкретное, например, хорошо внедряет ОТМ. Не вообще системы, связанные с логистикой, не вообще приложения от Oracle, не вообще имеет опыт в консалтинге, а конкретно хорошо внедряет конкретное решение для конкретных транспортных задач.

Глядь: опять перед ним землянка; 

На пороге сидит его старуха, 

А пред нею разбитое корыто.

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

9fdab8d783bc

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

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

Чуть менее честные и менее компетентные компании желая приблизить долгожданный момент подписания контракта скорее всего пойдут на поводу у заказчика, приободряя себя мыслью, что потом всегда можно будет выкрутиться. А потом снова два варианта. Либо делают как считают нужным/как позволяет система/сколько хватает знаний и с позиции силы объясняют, что границы проекта изначально были невыполнимы/не ясны/не формализованы. Либо реально предпринимают попытки точь-в-точь/в лоб/на зло исполнить требования заказчика и увязают в бессмысленных кастомизациях, которые далеко уводят от стандартной функциональности системы. Оба варианта приведут заказчика к разочарованию, обманутым надеждам и неоправданным ожиданиям от долгожданной автоматизации.

06labb2dp1221904452

Сказка ложь, да в ней намек!

Добрым молодцам урок.

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

Будьте хозяевами своего проекта и сразу включайтесь в работу, которую без вашего участия либо не сделают, либо сделают не так. Оставьте сразу эту иллюзию, что раз вы Заказчик, то работать придется только Исполнителю проекта. В правильной методологии Заказчику отводится почетное место и немало важных для общего успеха задач.

Будьте хозяевами своего бизнеса и относитесь к информационной системе как к его важной части. Чем более практически вы подойдете ко всему процессу, тем лучше — начиная от оценки реальных выгод от использования системы и заканчивая тестированием на жизненных примерах. За вас этого никто не сделает ни за какие деньги. Не забывайте, что консультанты по информационной системе далеко не специалисты непосредственно в вашем бизнесе, даже если иногда в их глазах проскакивает искра разума. ЧТО делать знаете только вы, а система только может предложить КАК это делать.