Пример

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

На следующий день ваша дочь приносит домой свою работу с исправлениями. Она получила итоговую оценку «хорошо». Вверху страницы стоит комментарий «Молодец!»

Норм?!. Больше в тесте не отмечено ничего определенного. В вопросах с несколькими вариантами ответа не указано ни одной ошибки. В конце этого раздела написано «Хорошая попытка!»

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

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

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

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

«Хорошо, — говорит руководитель проекта. — А какие показатели мы должны отслеживать, чтобы быть уверенным, что вы получаете пользу от этого проекта?»

«Показатели?» Вы не совсем понимаете вопрос.

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

И здесь вы совершаете вторую, также фатальную ошибку. Вы даёте один из следующих ответов:

1. «У нас нет времени на измерения». (Другой вариант: «Это1,411 не включено в бюджет»).
2. «Мы уже знаем, что все наладится, так зачем беспокоиться?»
3. «Мы не можем определиться с KPI». (Другой вариант: «У нас уже и так слишком много KPI»).
4. «Проект уже согласован».
5. «Мы не хотим знать, насколько ужасным было наше положение». (Другой вариант или дополнение: «Мы не хотим, чтобы кто-нибудь узнал, насколько ужасным было наше положение»).

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

«Хорошо»!

Но эта оценка нереалистичная, она основана на неполной информации без конкретных цифр, её обосновывающих.

Дяденька, дай миллиончик!..А лучше 50 и в долларах!..И всё будет даже лучше, чем ха-ра-шо!...

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

• Мы оптимизируем наш процесс продаж.
• Мы ускоряем наши процессы.
• Мы снижаем уровень запасов.

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

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

Я провожу семинары для топ-менеджеров по проектам внедрения корпоративного ПО с 1996 года, и моя клиентская аудитория состоит в основном из высшего руководящего состава и небольшого числа первых заместителей директоров. Первый вопрос, который я всегда задаю высокопоставленному участнику (почти всегда это генеральный директор): «Для чего вам этот проект?» Однажды я получил блестящий ответ от руководителя нефтегазовой компании: «Потому что, когда нажимаю на педаль газа, ничего не происходит». Этот мудрец имел в виду, что его компания не успевает вовремя изменять бизнес-процессы, чтобы сдерживать угрозы или использовать возможности. В результате в этом проекте внедрения акцент был смещён на развитие гибкости бизнес-процессов и отслеживание количественных показателей. Благодаря этому проект превратился в успешный.

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

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

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

Клиент: зачем измерять показатели эффективности?

Я: потому что если этого не делать, вас уволят.

Клиент: почему?

Я: потому что «Все стало намного лучше» — это крайне неудачный ответ на вопрос совета директоров: «Что мы получили в результате инвестиции 50 миллионов долларов?».

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

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

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

Числа — это хорошо, а хорошие числа — ещё лучше!

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

Рис. 1. Цепочка создания добавленной стоимости

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

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

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

• PI — показатели эффективности;
• KPI — ключевые показатели эффективности;
• API — аналитические показатели эффективности;

В некоторых случаях там оказываются и просто мусорные данные.

Далеко не все показатели являются ключевыми.

Пример

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

Обратите внимание: общее время, затраченное на закрытие процедуры выдачи кредита, составляет почти полный день (0,94), а продолжительность процесса от начала до конца составляет 10,38 рабочих дней, то есть чуть более двух недель. Для оптимизации этого процесса следует обратить внимание на области, занимающие больше всего времени, а также на задержки в перерывах между задачами.

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

Для эффективного определения и измерения KPI необходимы следующие элементы:

• Операнд

  Какой аспект бизнес-процесса рассматривается (например, время на выдачу кредита).

• Операция

  Какое действие выполняется с операндом (например, уменьшение).

• Численно выраженный квантор

  Степень, в которой операция применяется к операнду (например, 10 %).

• Результат

  Каким будет ощутимый результат (например, 1 полный день).

Итого

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

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

Табл. 3. Пример матрицы ключевых показателей

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

Далее приводится пример определения KPI (табл. 4), которое возможно только при наличии как подробных данных бизнес-процесса, так и матрицы (наподобие вышеприведённой).

Табл. 4. Пример определения KPI

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

В табл. 5 приведены результаты трёх улучшений (A, B и C), которых удалось добиться.

Табл. 5. Результаты осуществления трёх видов разноплановых улучшений по обработке кредитной заявки

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

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

В случае с улучшением C клиент автоматизировал оценку залоговой стоимости, что ощутимо сократило время работы персонала и срок выполнения. Это улучшение «на основе SAP».

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

В табл. 6 приведён пример схемы распределения ответственности, которую необходимо применить.

Табл. 6. Схема распределения ответственности

Обратите внимание, что на этой схеме распределения ответственности не отведено места под обсуждение изменений между группой, ответственной за бизнес-процессы, и службой технической поддержки приложений. Единственный вопрос, который может между ними обсуждаться: может ли запрашиваемое изменение процесса резко отрицательно повлиять на само приложение (см. шаг 7)? Таким образом, концепция «координация бизнеса и ИТ» теперь заменена новой концепцией — «ИТ подчиняется задачам бизнеса». Эта концепция является гораздо более динамичной, чем её предшественница, которая слишком долго сдерживала эволюцию бизнеса.

Напоследок ещё несколько хороших слов о числах

• они всегда останутся такими же, как при первой встрече;
• они никогда не болеют;
• они не уходят в отпуск (доступны в режиме 24/7);
• они не обидчивы и не амбициозны;
• они никогда не обманывают;
• они не принадлежат к политическим партиям;
• они не зависят от настроения.

Автор

Майкл Доан (Michael Doane) является ведущим специалистом по корпоративным приложениям. Г-н Доан уже 40 лет работает в сфере бизнеса и информационных систем, в том числе 28 лет он проработал консультантом и отраслевым аналитиком. Он консультирует клиентов по стратегиям, внедрению и интеграции, выбору поставщика услуг и управлению, а также передовой практике и методам извлечения выгоды из инвестиций в корпоративные приложения.

Помимо руководства обучением в компаниях Grant Thornton и The Consulting Alliance г-н Доан руководил несколькими масштабными консультационными кампаниями для крупных предприятий, занимающихся системной интеграцией преимущественно в области финансов и логистики, в Северной Америке, Европе и Азии. Перед началом деятельности в сфере консультирования он был директором компаний Plessey Company Ltd. и Ferry Peter, подразделения компании Wiggins Teape, в Европе.

С 2001 до середины 2005 г. он был отраслевым аналитиком в META Group, где создал и возглавил группу Professional Services Strategies и был одним из участников группы Enterprise Applications Strategies. Он имеет множество публикаций (в том числе пять книг по SAP) и провёл более семидесяти семинаров для руководителей по стратегиям и передовым практикам в сфере корпоративных приложений.

Г-н Доан является автором Синей книги SAP, краткого бизнес-путеводителя по миру SAP, и Зеленой книги SAP, бизнес-руководства по управлению жизненным циклом SAP. Он провёл многочисленные семинары для руководителей в США и Европе по вопросам внедрения лучших практик, отдачи от инвестиций в информационные системы и управления жизненным циклом приложений.