Увеличение сроков внедрения решений SAP приведёт к уменьшению затрат и увеличению выгоды в долгосрочной перспективе.

Гонка за посредственностью: фальшивый Грааль ускоренного внедрения SAP-систем

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

Как есть — текущее состояние, «статус кво» бизнес-процессов.

Как будет — прямое преобразование процесса «как есть» в процесс «как будет», лишенный недостатков первого и приносящий планируемую выгоду.

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

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

Весной 1997 г. SAP предложила новую методологию Accelerated SAP, или ASAP. И название, и суть указывали на увеличенную скорость внедрения (accelerated — «ускоренный», ASAP — «максимально быстро»). Методология подразумевала более прямолинейный подход, пилотные внедрения, развертывание шаблонов; особый упор делался на применение рекомендованных практик (то есть процессов, которые уже показали свою эффективность). В скором времени почти все партнеры SAP по внедрению стали использовать ASAP в качестве основной методологии. Многие дополняли ее: вводили более действенные факторы стоимости, предусматривали управление организационными изменениями и факторы влияния руководства компании. Проблема в том, что почти все эти подходы позиционировались как «быстрые». Fast Track («Быстрый путь») Deloitte и Rapid Return on Investment (R2i; «Быстрый возврат инвестиций») BearingPoint — лишь пара примеров. (Даже Oracle Consulting назвали свою методологию Fast Forward — «Быстрая перемотка».)

В то время многие придерживались принципа «оснастить предприятие под завязку», и обслуживающие фирмы действительно рекламировали скорость, с которой они могли внедрить системы SAP. Речь шла о реализации проекта за восемь, за шесть и, наконец, за три месяца. Я бы не удивился, увидев заголовок вроде «Roadrunner Corporation внедряет решение SAP во время обеденного перерыва!».

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

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

В проектах внедрения SAP-систем скорость губительна

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

Рис. 1. Стадия планирования и реальность жизни с SAP

Итак. На предприятии внедрено решение SAP. Что дальше?

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

Я рекомендую каждой организации, раздумывающей об ускоренном внедрении систем SAP, ознакомиться с результатами исследования, которое я провел несколько лет назад (см. Табл. 1).

Табл. 1. Опрос клиентов корпоративных приложений о нерешённых проблемах, оставшихся с внедрения

Продолжительные негативные последствия А, Б и Г являются прямым результатом спешки, а Д — плохой подготовки клиента к проектированию бизнес-процессов.

Отсутствие количественной оценки указывает на то, что установка системы SAP на предприятии — средство осуществления процессов, а не стратегический инструмент.

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

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

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

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

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

Компания SAP решила пойти ва-банк и в сентябре 2010 года представила публике решения для быстрого развертывания RDS (Rapid Deployment Solutions). Новая попытка предложить «готовые к развертыванию» конфигурации SAP-систем немногим отличается от предыдущих, когда клиентам нужно было лишь адаптировать рабочий процесс для перехода к продуктивной эксплуатации. Внедрение ускорялось за счет отказа от фаз концептуального планирования и конфигурирования. Клиент получал готовые бизнес-процессы, которые сразу мог начать использовать. На долю указанных двух фаз приходилось 50–60 % (или больше) времени и бюджета, выделенных на весь проект внедрения по методу ASAP, и без них клиент, предположительно, экономил и то, и другое.

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

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

Иллюзия простоты внедрения SAP «в базовой комплектации»

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

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

В качестве примера для пункта «а» можно привести компанию Marin County and Waste Management (как и множество других клиентов, которые, впрочем, не всегда судятся со своими системными интеграторами).

Пункту «б» соответствует такое огромное множество клиентов, что и сосчитать не возьмусь.

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

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

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

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

В процессе лицензирования ПО клиенты часто меняют стратегию в пользу беспорядочного концептуального планирования и становятся жертвами недобросовестной работы по нескольким фронтам:

1. Лица, ответственные за закупки ПО для клиентов, не до конца понимают, что такое «применение рекомендованных практик SAP». Более того, они чаще всего не являются заинтересованными лицами, которые должны эти самые практики применять.
2. Большинство клиентов не делают различий между программированием и конфигурированием и поэтому не способны понять, насколько последующая пользовательская настройка может снизить выгоду от приобретения «базовой комплектации».
3. Менеджеры по работе с клиентами часто получают комиссионные за продажу лицензий, а не за удовлетворенность клиента впоследствии или внедрение в установленные сроки.
4. Как я уже упоминал, клиенты, перенимающие рекомендованные практики, часто не понимают долгосрочного характера владения продуктами SAP и поэтому недооценивают вредное влияние обобщенных решений, не учитывающих конкретный бизнес-процесс.
5. Во время продажи редко оценивается способность клиента провести эффективное концептуальное планирование.

В группу представителей клиента, договаривающихся о покупке лицензии на ПО SAP, редко входят люди, которые впоследствии станут участниками проекта внедрения, в частности, на этапе концептуального планирования. Именно членам проектной группы приходится разбираться с последствиями обобщенного решения перенять рекомендованные SAP процессы. Этим участникам, попавшим в ловушку «базовой комплектации SAP», никакие средства не помогут смягчить разрушительные последствия.

Системный интегратор (СИ) представляет рекомендованный бизнес-процесс стороне клиента.

Клиент: Нет, мы работаем не так.

СИ: Но вы ведь сможете адаптироваться к этому процессу?

Клиент: Нет, в нем не хватает необходимых нам этапов (мы уникальны.)

СИ: Но вы сказали, что будете использовать рекомендованные практики.

Клиент: Рекомендованная практика — процесс, который мы сейчас используем (мы сами его придумали.)

СИ: Но в техническом задании сказано...

Клиент: Неважно, что там сказано. Мы так делать не будем (я начинаю злиться.)

Повторите приведенный диалог пятьдесят–сто раз. Каждый раз говорите громче.

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

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

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

Поднимаем планку: не просто «переход к продуктивной эксплуатации»

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

Вряд ли инвесторы, направляя миллионы долларов на приобретения и внедрения, рассчитывали именно на это. Стремление провести внедрение как можно быстрее и срезать все возможные углы приводит к тому, что «продуктивная эксплуатация» систем превращается в постоянную борьбу за их жизнеспособность. Более того, большинство клиентов обнаруживают, что после запуска системы в продуктивную эксплуатацию начинается период «утряски». Этот период может продлиться год, два или три, пока не будет стабилизирована работа приложений, в которые было вложено столько средств (Рис. 2).