Новый маркетинг

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

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

Это набор схем, правил креативного поиска идей. Например, метод сопоставления разнородного: нужно взять две несвязанных вещи и придумать между ними связь. В результате мы должны получить креативную идею. Если применить ее к одной из частей маркетинг-микса, мы получим латеральный маркетинг.

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

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

Проблемы, которые могут возникать при внедрении ERP систем

Проблемы, которые могут привести к описанному выше развитию событий, следующие:

1. Функциональные требования формулируют пользователи

2. Функциональные требования к модификации подменяются описанием модификации

3. Руководство заказчика отказывается от скрупулезной оценки экономического эффекта от каждой модификации.

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

Каковы причины и последствия перечисленных проблем?

Ошибка первая, она же основная: требования формулируются пользователем

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

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

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

Обоснование ошибочности данного решения можно сформулировать следующим образом.

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

Возникающую в результате такого подхода избыточность требований к модификации можно продемонстрировать следующим образом. Предположим, что при описании вариативности реализаций некоторого автоматизируемого бизнес-процесса работает упрощенное правило Парето 20/80 (используем правило Парето просто как пример закономерности, которую принято применять для описания практически любых несложных экономических закономерностей). В этом случае 20% вариантов реализации (частных случаев) бизнес-процесса составляют 80% всех случаев реализации. 36% вариантов реализации — 96% всех случаев. 49% вариантов реализации — 99% всех случаев.

Представленные цифры наталкивают на мысль, что с точки зрения того, кто платит за модификацию, при определенных условиях может иметь смысл ограничиться автоматизацией, допустим, 36% вариантов реализации. Таким образом, 96% всех реализаций система будет обрабатывать автоматически, оставшиеся же 4% реализации может быть целесообразным оставить для полуавтоматической обработки (по каждому из них пользователь должен будет принимать индивидуальное решение).

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

Пользователь же, как показывает практика, в большинстве случаев уверен, что автоматизация 50% частных случаев — несуразно малый результат. Тот факт, что эти 50% закрывают 99% всех реализаций процесса, его вряд ли впечатлит: ведь он видит, что оставшиеся 50% частных случаев, как бы редко они не случались, придется разрешать «руками». Поэтому пользователь готов долго и вдумчиво прорабатывать частные случаи, бесконечно расширяя требования к системе.

Ошибка вторая, отягчающая: согласовываем «как» вместо «зачем»

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

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

Исключения

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

Описанные проблемы не относятся к «пользователям-исключениям».

Если две ошибки допущены: как искать выход

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

Выход первый: смириться и стараться помочь пользователю формализовать, описать и реализовать его предложения. Это может оказаться очень выгодно в краткосрочной перспективе, особенно в случае, если заказчик оплачивает работы по принципу «time & material». Однако мы все понимаем, что это, во-первых, просто непорядочно со стороны исполнителя, а во-вторых, это неоправданно в долгосрочной перспективе: рано или поздно встанет вопрос, каким образом автоматизация малозначительного бизнес-процесса обошлась заказчику в сумму, превосходящую всякие представления не только об экономической целесообразности, но и об элементарном здравом смысле. Ведь в итоге, как всем известно, честным быть выгодно.

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

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

Ошибка третья, контрольная: заказчик платит не глядя

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

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

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

Все ошибки допущены. Что делать

В заключение хотелось бы описать рекомендации, отвечающие на вопрос «Что делать?», для участников тех проектов, которые уже увязли в подобных проблемах. Поскольку последовательное описание рекомендаций потребовало бы значительного объема, ограничимся краткими тезисами.

Для начала рекомендуется последовать правилу, общему для всех конфликтов: поговорить «об этом» с партнером. В данном случае требуется тактичный, но искренний разговор ключевого представителя заказчика с вызывающим у него наибольшее доверие представителем компании-исполнителя. Необходимо понять, какие из перечисленных выше проблем реально существуют. Если обнаружится, что заказчик четко видит проблему, а исполнитель настаивает на том, что все нормально, это может указывать на то, что исполнитель не ориентирован на долгосрочное сотрудничество. В этом случае лучше сменить исполнителя.

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

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

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

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

Из сказанного выше следует, что при приемлемом уровне квалификации исполнителя вывести из штопора отношения, подорванные потерей доверия, вполне возможно, причем это может оказаться проще и дешевле, чем менять партнера. Главное — правильно определить корень проблемы. Тогда развитие системы вновь станет для заказчика тем, чем оно должно быть: мощным инструментом развития собственного бизнеса.

ERP системы. Развитие и внедрение

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

Специфика восприятия

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

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

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

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

Отдача на инвестиции

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

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

Особенности проектирования

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

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

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

Взгляд участника: как рушатся отношения. Краткая хронология

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

Руководство заказчика предлагает пользователям поучаствовать в автоматизации своих процессов: проработать совместно с консультантами свои требования к системе.

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

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

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

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

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

При этом, чаще всего, и после смены подрядчика повторяется та же картина: материальные потери и нереализованные модификации, тормозящие развитие бизнеса.

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

Управление проектом внедрения ИС

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

Один восточноевропейский банк за пять лет потратил около 50 млн евро на создание системы управленческой информации. Он приобрел самую производительную платформу (аналогичную используют Wal-Mart и другие крупнейшие ритейлоры) и три года содержал команду консультантов, которые «настраивали функциональность системы управленческой информации». Однако, по признанию финансового директора, у руководства банка до сих пор нет данных, необходимых для управления издержками и принятия стратегических решений (например, о выводе на рынок нового продукта).

Что же было сделано не так? Дело в том, что решения в данном случае принимались по обычному для таких ситуаций алгоритму: задом наперед. Внедряя MIS, призванную обеспечить необходимой информацией руководителей компании, в первую очередь нужно было определить, какая информация нужна им. Если, как чаще всего бывает в таких случаях, технические специалисты самостоятельно принимают решения, то они исходят из технических качеств системы и не ориентируются на требования бизнеса.

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

Финансирование уменьшается на сумму, равную 50% от предполагаемой. Топ-менеджеры крупной европейской страховой компании ежемесячно получают отчеты об эффективности ИТ-проектов; при этом критерии оценки оговариваются еще до их начала. Благодаря такому подходу подразделения предлагают лишь те проекты, в необходимости которых они полностью уверены, и прикладывают все усилия, чтобы внедрение новой системы как можно быстрее принесло результаты.

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

Так, если говорить о внедрении комплексной системы, то, например, современные ERP-системы состоят из более чем десяти модулей — от финансового до управления персоналом, и для полномасштабного их внедрения нужен не один год. В то же время опыт показывает, что проекты, затягивающиеся больше чем на полтора года, обычно терпят неудачу, поскольку за это время меняется и сама компания, и внешние условия. Это актуально прежде всего для стран с развивающейся экономикой.

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

Как управиться с основными рисками, сделать так, чтобы проект не начал буксовать, а сотрудники не потеряли веру в его успех? Рамки статьи не позволяют нам дать исчерпывающее описание всех аспектов управления крупным проектом, но мы сформулируем несколько основных правил и обратим внимание на некоторые подводные камни.

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

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

Вопрос учета в системе требований бизнеса относится к важнейшим, поскольку касается управления масштабом проекта. Изменения неизбежны, но, если не расставить приоритеты, коррективы могут вноситься бесконечно. В одной российской компании на всю работу по изменениям было отведено 2000 человеко-дней, однако, когда все бизнес-подразделения сформулировали свои требования, оказалось, что нужно 8000 человеко-дней! Изучив ситуацию, мы обнаружили, что запустить проект можно было без солидной части предлагаемых изменений; более того, во многих предложенных изменениях не было ровным счетом никакой необходимости.

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

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

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

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

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

В одной восточноевропейской финансовой компании крупный ИТ-проект явно пошел не по плану (рассчитанный на два года, он растянулся на три, а бюджет был превышен на 40%), все его основные участники пребывали в полной растерянности, любая активность казалась бессмысленной. К примеру, миграция данных была названа проблемой, потому что «ничего не работает». Нам потребовалось больше недели, чтобы понять, что на самом деле означало это «ничего не работает». Все свелось к двум проблемам — одной довольно мелкой технической и еще одной организационной.

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

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

Нередко бизнес-подразделения формулируют свои требования, а затем на долгие месяцы «забывают» о проекте и начинают проявлять активность уже в момент испытаний системы, которые, при таком отношении со стороны бизнеса, как правило, оказываются неудачными. Хотя после утверждения технических спецификаций общее направление проекта обычно не меняется, примерно 80% решений, напрямую сказывающихся на удобстве и полезности системы для пользователя, принимаются уже после разработки спецификаций и до приемочного тестирования. Таким образом, если будущие пользователи системы не участвуют постоянно в процессе принятия решений, то впоследствии они обнаруживают, что результат не соответствует их ожиданиям, возникает масса ошибок в процессах, которые проявляются потом при взаимодействии с клиентами, и компании приходится вносить все новые коррективы.

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

Обоснование проекта по внедрению ERP систем

Многие руководители по своему опыту знают, что крупные ИТ-проекты — будь то внедрение ERP и CRM, замена биллинговых приложений в телекоммуникациях или внедрение систем управленческой информации (MIS) — часто требуют гораздо больше ресурсов, чем представлялось поначалу. Перерасход финансовых средств при внедрении, например, ERP-систем составляет в среднем 90%, а перерасход времени — 120%. Чем объясняется столь неутешительное положение дел?

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

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

Таким образом, успех любого крупного ИТ-проекта зависит в первую очередь от понимания бизнесом оснований для его запуска и умения бизнес-менеджеров взять на себя инициативу в установке его приоритетов. Еще один немаловажный фактор успеха — способность руководителей обеспечить различные механизмы реализации проекта. Взглянем на некоторые наиболее важные аспекты управления крупным ИТ-проектом с точки зрения бизнес-менеджера.

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

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

Пример типичного проекта, непосредственно направленного на улучшение экономических показателей, — внедрение CRM-системы. При планировании подобных инвестиций бизнес-менеджерам нужно действовать так же, как если бы речь шла о «нормальном» бизнес-начинании. Ведь, скажем, если начальник отдела продаж попросит увеличить штат своего подразделения на 200 человек, любой руководитель потребует от него скорректировать план продаж на следующий год, и это будет воспринято как совершенно справедливое требование.

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

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

Внедрение единого решения от одного поставщика или установка промежуточного программного обеспечения, позволяющего состыковать разрозненные части инфраструктуры, позволяет обновить архитектуру и сократить затраты на поддержку информационных систем. В свое время именно это стало для западных компаний важным стимулом к внедрению ERP: одна глобальная нефтяная компания благодаря ей отказалась от 350 систем. В то же время если снижение издержек на обслуживание — основная цель внедрения нового единого решения, то компании нужно проявить твердость и отказаться от других систем; следовательно, ИТ-подразделение должно заранее предусмотреть соответствующие мероприятия. Что касается автоматизации, то она позволяет снижать издержки, например, за счет сокращения персонала в бэк-офисе, уменьшения запасов, увеличения скорости процессов и т. п. Однако, чтобы это произошло на деле, соответствующие бизнес-подразделения должны не только доказать свою способность реализовать обещанные эффекты, но и принять обязательство (и отразить его в бизнес-плане) сделать это в определенные сроки.

Часто прогнозировать непосредственный финансовый эффект от реализации крупного ИТ-проекта трудно, однако он может быть совершенно необходим или целесообразен. К жизненно важным можно отнести проекты, направленные на устранение очевидной технологической отсталости — такие инвестиции нужны просто для того, чтобы бизнес остался на плаву. Но нередко благодаря крупным внедрениям появляются условия для развития компании на новом уровне. Прежде всего это касается таких проектов, как создание систем управленческой информации или внедрение ERP-систем. В этом случае, как мы отмечали выше, вполне реально добиться измеримых улучшений, но на деле основные преимущества для компании возникают благодаря формируемой ERP инфраструктурной основе для будущего развития компании в целом и ее информационных возможностей в частности. ERP-системы (если их грамотно внедрять) как никакие другие позволяют интегрировать информацию, унифицировать бизнес-процессы (и за счет этого сделать компанию гораздо более прозрачной для руководства), а также облегчить дальнейшее развитие ИТ-приложений. Они становятся своего рода административным и информационным «позвоночником» организации. Непосредственный финансовый эффект от таких вложений обосновать сложно, но в определенный момент внедрение ERP-системы оказывается необходимым условием для дальнейшего устойчивого развития крупной компании. В то же время, учитывая размер вложений и необходимость тратить на внедрение систем рабочее время сотрудников, каждой компании нужно четко понимать, готова ли она пойти на эти расходы и для чего она это делает.

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

Не стоит и излишне бюрократизировать процесс принятия решений — здесь вполне работает правило 80/20: у 80% всех проектов есть финансовое обоснование, а остальные 20% могут без него обойтись.

Тренды есть и у продаж! MI-centre

Смотреть по сторонам или опираться на статистические данные, так что считать умеет каждый, но лишь увидевший причинно-следственные связи по-настоящему ценнен”

Начнем сразу!

3 основных тренда

1. Только 30% компаний Москвы (около 40 000 юр. лиц по состоянию на 2010 год.) действительно озабочены качеством продукции и системами клиентоориентированности.

2. Продают только первым лицам (b2b), так как только у них есть свободные финансовые средства и они могут ими распоряжаться.

3. Эпоха разовых трансакций умирает – да здравствует сервис!

Вежливо, звоня первому лицу, вместо впаривания продавайте партнерские отношения!