Академия передовых практик внедрения  и поддержки SAP

23-24 мая 2013 года

Бизнес-Школа «Сколково»

Докладчик: Д-р Юрген Отт, ex-CFO Allianz Insurance

Dr.Juergen Ott, ex-CFO Allianz Insurance

Как запустить систему в продуктивную эксплуатацию и остаться в живых

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

Однажды мы проводили такой проект с коллегами из группы управления активами в Германии. Менеджер проекта приехал, рассказал о своем успехе и сказал: «Знаете, есть у нас один секрет успеха и бесшовного перехода в продуктив». Как вы думаете, что это был за секрет? Оказывается, команда проекта на 2/3 состояла из женщин, и на 1/3 – из мужчин. Оказалось, что выход в продуктив облегчается высоким количеством женщин в команде проекта. Мужчины постоянно все обсуждают, причем основательно и часто агрессивно. Женщины – намного более практичные существа: вот у них есть работа – ее нужно выполнить. Я так это объясняю. Это секрет успеха. Конечно, есть и другие факторы, которые нельзя сбрасывать со счетов.

Итак, допустим, у нас есть структура, точнее, конгломерат – 1700 юридических лиц. Есть среди них компании по 20 человек, а есть и по 36000 сотрудников. В общем, 120 000 сотрудников во всем мире, 7500 – в финансах: бухгалтерия, контрагенты, актуарии, управление рисками, отчетность, налоги, а также поддержка IT – какое-то количество сотрудников из IT-поддержки у нас относились к блоку финансов. У нас было до 650 отдельных гроссбухов, то есть отдельных бухгалтерских балансов; были отдельные компании, инвестиционные банки, и множество компаний разных видов. У нас было 55 разных инсталляций SAP – разные версии, разные релизы, разные настройки. Децентрализованная культура преобладала в компании. Мы хотели сделать более совершенной функцию финансов, начали с гармонизации и стандартизации процессов и систем. Ключ к успеху, с моей точки зрения - полный реинжиниринг процессов в соответствии с передовой практикой. Мы ее вырабатывали сами, у нас были заранее сконфигурированные предложения, так называемые templates (шаблоны) SAP, и необходимо было обеспечить постоянное совершенствование процессов и технологий.

Как я уже говорил, мы обменивались передовой практикой в рамках нашей группы, между разными подразделениями и компаниями, и поэтому провели реинжиниринг бухгалтерии, контроллинга, сверки и консолидации отчетности в процессе IT-имплементации и процессов апгрейда. То есть мы сфокусировались на бизнес-процессах, и в этой работе мы опирались на несколько ключевых принципов. Например, мы перешли на международные стандарты бухгалтерского учета, это была своего рода революция, потому что тогда в каждой стране мира были свои принципы бухгалтерского учета. Причем эти принципы сформировались век назад, два века назад и так далее. К тому же все компании работали в разных средах: кто в Excel, кто не в Excel, какие-то компании были на Нью-Йоркской бирже, нужно было соблюдать американское законодательство из-за этого – чего только не было!

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

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

У нас было такое количество унаследованных систем! Когда мы дошли до 3400 унаследованных систем, я остановился и перестал считать, просто мне надоело. И каждая из этих систем была – управление активами, банки, страхование, отчетность, то есть это были действительно ключевые бизнес-системы. У нас было 3400 интерфейсов, соответственно, их все нужно было подсоединить к стандартной саповской ERP-системе. Это потребовало очень много сил. Что касается данных, тут мы стандартизировали план счетов, все мастер-данные, все данные, необходимые для отчетности (внутренней и внешней) регулирующих органов.

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

Впервые у нас была внедрена политика регулярных апгрейдов и апдейтов. Сначала мы говорили, что нужно их делать в ежегодном режиме, потом перешли на режим раз в два года. Раньше у нас было 55 инсталляций SAP, и совершенно непонятно, как в этих условиях удавалось выпускать релизы и апдейты, как этим всем можно было управлять. У нас было очень много собственных программистов; мы покупали программное обеспечение, платили за лицензии, потом нанимали программистов, чтобы кастомизировать это программное обеспечение. Естественно, через несколько лет было уже невозможно установить стандартный или новый релиз, потому что система изменилась до неузнаваемости. Поэтому мы договорились придерживаться стандартного программного обеспечения, регулярно делать апдейты. Мы и так платим за лицензии.

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

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

Что касается стандартных приложений. Операционные системы, локальные системы, унаследованные системы (про которые нам говорили, что у нас они – лучшие в своем классе) – у было все это плюс стандартные приложения SAP. В штаб-квартире мы тогда еще использовали BC S для консолидации и CC S для фиксации данных и для создания отчетности на уровне группы.

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

Многое зависит от того, насколько хорошо проработан Blueprint, вот этот вот концептуальный проект.

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

У нас есть стандартные настройки по документированию процесса, одобрения, согласования, внесения изменений и так далее. Все очень высоко дисциплинировано, потому что это такой немецкий подход. Это не просто бумажка, которую мы написали или распечатали и подшили в папочку, – нет, мы работаем с этими документами. Я действительно верю в то, что если вы эксперт (а я, например, бухгалтерией занимался 20 лет), то чем дольше вы занимаетесь своим делом, тем в меньшей степени вы делаете это осознанно. Вы уже переходите в какой-то «автопилот». А в проекте по управлению изменениями как раз требуется осознать, что именно вы делаете, артикулировать это, сформулировать.

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

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

Рекомендация

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

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

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

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

Что касается аппаратной инфраструктуры, то мы договорились, что у нас будет не больше 2-3 версий хранилищ данных, чтобы не плодить разные «железяки». Это как раз позволяет нам подготовиться к будущему сокращению затрат. Дальше – следующие задачи: безопасность, стратегия доступа, стратегия новых релизов и апдейтов и т.д.. Мы попросили аудиторов, чтобы они тоже описали свои процессы, получили свои интерфейсы, подключился и центр компетенции и т.д. – все было детально описано, валидировано, оценено и утверждено. Только после того, как договорились о стандарте, мы приступили к настройкам системы и к ее кастомизации.

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

1. Внедрены ли все ключевые системы были внедрены;

2. Соответствует ли это стандарту;

3. Все ли мастер-данные присутствуют, насколько хорошо работают функции.

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

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

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

Рекомендация

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

Еще один ключ к успеху для безболезненного выхода в продуктив – это иметь какой-то процесс на непредвиденные случаи, потому что все равно что-то упустите. У вас должна быть определенная процедура – что делать, когда неожиданно возникает проблема. Мы закладывали на проект 2-2,5 года и на тесты отводили минимум 6 месяцев из этих 2-2,5 лет. Результаты всех тестов, проводимых на локальном уровне, должны были докладываться в центр, центр должен был знать обо всех проблемах, которые были выявлены.

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

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

1. технический (то есть по аппаратным средствам, по «железу») – программисты, например, у нас как раз уходили в эту команду, разработчики.

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

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

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

Во время проекта в некоторых наших компаниях пропорция была такая: 70% консультантов и 30% собственных. А были и другие случаи: 20% консультантов и 80% собственных сотрудников. Все зависит от отправной точки, то есть из какого состояния начинает трансформироваться ваша компания, ваше подразделение и т.д., сколько опыта есть по управлению проектами, управлению изменениями в этой группе людей и в этой компании, какой опыт у них есть по работе с SAP.

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

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

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

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

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

Об авторе

Юрген Отт – советник по вопросам бизнес-транформации. Имеет степень доктора экономических наук. До выхода на пенсию в 2011 году успешно реализовал масштабную программу по реструктуризации бизнеса, трансформации финансовой службы и автоматизации бизнес-процессов в компании Allianz Insurance AG. В числе выполненных проектов – реализация директивы Solvency, программы Global Reporting, проведения слияния Allianz Insurance AG и Dresdner Bank.

До прихода в Allianz Insurance AG работал в компании Daimler Benz, где курировал вопросы слияний и поглощений, внутригруппового контроллинга, анализа финансовых потоков и перевода на GAAP.