Начинать любой проект необходимо с прояснения пользы (value) и выгод (benefit), которые он должен принести. При этом важно помнить, что проект редко напрямую создаёт ожидаемый эффект (outcome). Дело часто ограничивается промежуточными результатами, предоставляемыми на выходе (output). А получение пользы и выгод с помощью таких результатов происходит за рамками проектной деятельности.
Простой пример — сайт для заказа пиццы. На выходе из проекта по его разработке появится только некий сервис, за содержание которого придётся регулярно платить. Зачем это нужно? Затем, что если сервис выйдет удобным и начнёт экономить время, то клиенты назовут его «полезным». А если растущие доходы перекроют понесённые затраты, то и владелец пиццерии признает затею «выгодной».
Вопрос «Зачем?» является здесь ключевым. Он фокусирует главную цель проекта на ожидаемой пользе и выгодах. Этот коварный вопрос — настоящий санитар леса, гроза розовых единорогов и воздушных замков. Когда в очереди скопились сотни проектов, анализ пользы и выгод — хороший способ распознать все сомнительные инициативы и оставить самые перспективные.
Проекты информатизации не являются исключением, но выявить их настоящие цели довольно сложно. Это связано с огромным расстоянием от выходов ИТ-проектов до той реальной пользы, которую они обеспечивают. Как с этим справляться?
Роль информатизации
В поисках пользы от информатизации лучше оставить информационные технологии в стороне. Они имеют дело с объектами «информационного мира» и сами по себе никому не нужны. Ещё Ходжа Насреддин отмечал, что от цифровой халвы во рту не становится слаще.
Это не значит, что информационные технологии бесполезны. Напротив, они важны для успеха современного предприятия. Поэтому обсуждение модных Digital ABC’s (они же AI, Big Data и Cloud Computing) всегда вызывает большой энтузиазм. Но как только речь заходит об оценке ожидаемой пользы и выгод, разговор сразу же переключается на жизнь во всех её проявлениях, кроме секса и цифровой трансформации.
Информационные системы полезны только там, где помогают повлиять на объекты «физического мира». Например, повысить отдачу производственной линии, увеличить продажи или навести порядок на складе. Обратное неверно. Никто не станет заводить автопарк, чтобы только оправдать наличие шикарной системы учёта автотранспорта.
Может показаться, что даже упоминать о таких очевидных вещах как-то неприлично. Однако, подавляющее большинство айтишников не постесняется произнести вслух, что «главной целью проекта является внедрение ERP-системы».
Не стоит ставить морковку позади лошади. Информационные системы хотя и важны, но всё же являются только частью предприятия, и полезны только для обеспечения его основной деятельности. Это касается даже тех предприятий, чья продукция неразрывно связана с информационными технологиями.
Информатизация всегда должна изменять что-то внутри предприятия так, чтобы оно приносило больше пользы клиентам и выгод владельцам. Причём речь о пользе именно в физическом, а не в информационном мире.
На практике это означает, что ИТ-проект никогда не возникает в гордом одиночестве. Он всегда должен быть связан с вышестоящей программой организационного развития, которая должна работать на портфельную стратегию предприятия. И в идеальном мире мотивационная часть проекта, связанная с пользой и выгодами, конечно же найдётся у директора по развитию или в корпоративном проектном офисе.
К сожалению, качественная документация программы или портфеля — редкий зверь, достойный Красной книги. Даже если обнаружится что-то похожее, лучше лишний раз всё перепроверить, чем потом закапывать в землю миллионные бюджеты.
Поэтому первым делом стоит самостоятельно выяснить как ИТ-проект может помочь предприятию в создании пользы и выгод. Сделать это не так сложно, как кажется.
Анализ потока пользы
Компактную систему понятий для разговоров «о создании пользы на предприятии» задаёт концепция «потока создания пользы» (value stream). Эта концепция вводится в дисциплине «Бизнес-архитектура» (business architecture), представленной стандартами BIZBOK и OMG:O-BA, а также используется в ITIL, TOGAF и самых популярных «гибких» подходах к информатизации — SAFe: Scaled Agile Framework и DAIT: Disciplined Agile IT.
С точки зрения создания пользы (value), предприятие моделируется в виде набора способностей (capability), превращающих потоки материальных ресурсов в полезный продукт (product) или сервис (service). Полезность продукции проявляется в сценарии (scenario) конечного потребителя. Разные способности могут участвовать в создании пользы непосредственно, или же оказывать поддержку остальным. Информационные технологии чаще всего относятся к последнему типу, улучшая работу всех остальных способностей предприятия.
Это очень простая модель, позволяющая говорить о том как предприятие выполняет свою основную функцию (т.е. миссию), не рассматривая при этом его организационную структуру, процессы, персонал, данные, технику и софт.
Выход на пользу ИТ-проекта, например на заводе по производству химических удобрений, может выглядеть так:
— Нам нужна новая ERP-система
— Зачем?
— Чтобы поддержать процессы производства, которые мы существенно изменим в ближайшее время (способность планирования)
— Зачем их менять?
— Чтобы предприятие смогло перейти на работу по индивидуальным клиентским заказам, а не просто заполняло склад (способность производства)
— Зачем это понадобилось?
— Клиенты хотят учитывать элементный состав почвы на конкретных полях, для которых предназначены наши смеси (способность кастомизации)
— Зачем это клиентам?
— Индивидуальный подбор удобрений повышает урожайность на 50% при меньшем объёме химикатов (польза)
Искомая польза — ответ на вопрос «Что?» создаётся в реальном мире, чтобы клиент захотел за это заплатить. И это не ERP-система, не производственная линия и даже не сами «умные удобрения», а повышенный на 50% урожай с его полей.
При выборе конечного потребителя в потоке создания пользы нужно выходить за границы предприятия и дотягиваться до клиента, приносящего деньги. Местечковая оптимизация отдельных подразделений не учитывает глобальные интересы бизнеса и уменьшает выгоды для предприятия в целом. Этот тезис хорошо раскрыл Голдратт в своей «Теории ограничений».
Максимальную выгоду для предприятия приносит размышление о сквозных потоках создания пользы «от потребности до удовлетворения клиента». Именно это называется «клиентоориентированностью» в системном смысле. Никакие другие «эмоциональные» определения не дают руководства к конкретным действиям.
В примере выше, повышение урожайности — это та самая польза в реальном мире, привязанная к сценарию клиента «выращивание полезных культур». Ради получения этой пользы клиенты заплатят деньги, которые при удачном раскладе оправдают все затраты на развитие предприятия.
В результате мы получаем ответ на вопрос «Что?» нужно создать в реальном мире для клиента с его сценарием, чтобы он заплатил. И это вовсе не «Новая ERP-система». Ход анализа для выхода на пользу можно изобразить в виде схемы:
Разговор обычно начинают со способности, которую планируется развивать. На этой схеме красный кружок «ИС» отвечает за изменение какой-то информационной системы. Вопросы «Зачем?» задаются по схеме последовательно «снизу вверх», пока не перейдут из контекста предприятия (т.е. обсуждения организации, бизнеса, продукта) к решению реальных проблем в сценарии клиента.
На этом этапе нужно уделять как можно меньше внимания контексту предприятия, и сосредоточиться на контексте клиента. Разговор в контексте клиента должен подвести к следующему рассуждению, называемому «предложением пользы» (value proposition):
Клиент извлекает Пользу в ходе выполнения какого-то Сценария. Этот Сценарий имеет сложное внутреннее устройство и содержит какой-то Потенциал для улучшения (проблему, возможность или просто JTBD). Продукт (или Сервис) эксплуатирует этот Потенциал, настраивая Сценарий на создание ещё большей Пользы.
В примере выше, аграрная компания (Клиент) получает урожай (Польза) в процессе выращивания и сбора сельскохозяйственных культур (Сценарий). Развитие технологий анализа почв создаёт возможность индивидуального подбора удобрений (Потенциал). Изготовление удобрений под заказ (Продукт) может повысить урожайность полей на 50% (больше Пользы).
Отвлекающие факторы
Если повезёт, то среди маркетинговых материалов отыщется готовое «предложение пользы», или среди инженерной документации найдётся «сценарий эксплуатации» под названием «Сценарий использования» (Use Case), «Концепция [стадии] эксплуатации» (OpsCon или Operational Concept) или похожим. Существует много методов и форматов описания сценариев создания пользы. Главное — знать что искать.
Но скорее всего, выявлять сценарий клиента придётся самостоятельно, с группой инициативных лиц. Чтобы процесс не растянулся на месяцы (и это не шутка!), важно придерживаться верного направления. Это не так просто, как кажется, потому что не только айтишники любят перетягивать одеяло в сторону своих ролевых интересов.
Важно следить за тем, чтобы разговор стремился к выходу на пользу для клиента. При этом возможностей для его отвлечения хватает, и многие из них кажутся весьма волнующими. На самом же деле они просто заводят анализ в тупик.
Часто о пользе клиента забывает инженер. В этом он похож на айтишника, потому что его Magnum Opus — это продукт, который необходимо изготовить, а также станок (или даже целый завод) для воплощения этого продукта в жизнь.
Разговоры о продукте легко распознать. Они погружают вас в технические детали, архитектурные решения, жизненный цикл, конфигурацию, расширенный функционал, соответствие всем стандартам в мире и управление через смартфон.
Нет, если инженер хороший, то всё работает! И не страшно, что пылесос весит под центнер и проходит в дверь только в разобранном виде. Зато встроенный голосовой помощник развлечёт несчастных в ходе двухчасового сеанса замены фильтров.
Инженерам лучше напоминать, что продукт очень важен, но клиент платит не за его внутреннюю технологичность. Перед тем как предлагать техническое решение, следует внимательно ознакомиться с условиями задачи.
Ещё чаще о пользе клиента забывает менеджер. Он, точно как айтишник, который видит везде только информационные системы, не замечает ничего кроме организации с её структурами и процессами.
Разговоры за организацию интересуют всех. Кто станет начальником, кому придётся впахивать, какая структура лучше для дела, какие ставить сроки и бюджеты, и главное — какие показатели премирования гарантируют качество, лидерство и командный дух.
Выходит всё в точности по Жванецкому. Коллектив и днём и ночью трудится, трубы дымят, жизнь кипит. Модернизировали, подхватили, перестроились, внедрили новый коэффициент… А пылесос включаешь — не работает.
Менеджерам стоит аккуратно напоминать, что организации очень важны, но клиент не платит за их огромную внутреннюю жизнь. Перед тем как что-то «организовывать», следует решить что требуется «предпринять».
Почти всегда пользу клиента игнорирует коммерсант. Он, подобно айтишнику, живущему в мире информационном, делает бизнес в мире деловом, точно так же далёком от реальности.
Разговоры за бизнес самые животрепещущие. Купить подешевле, продать подороже, товары против услуг, контракты и соглашения, цепочки поставок и логистика, налоги и кредиты, ROI и EBITDA, а также широкий, непересыхающий денежный поток.
Поднята на знамёна цель «делать больше денег сейчас и в будущем», заключены все контракты, распилены все откаты, и тянутся тяжёлые караваны к нездешним базарам. Только почему-то покупатель не спешит распахивать свой кошелёк.
Господам коммерсантам при каждом упоминании денег нужно пояснять: кто и за что их отдаст. Клиент готов заплатить в деловом мире, но только если получит сравнимую пользу в мире реальном.
Синтез бизнес-модели
Выявление пользы очень важно, потому что позволяет оценить всю задачу целиком, с высоты птичьего полёта. После её нахождения и согласования со всеми участниками можно начинать обратный путь. Теперь нужно восстановить все пропущенные детали в контексте предприятия, организации и главное — бизнеса.
Если анализ потока пользы нужен для ответа на вопрос «Что?» нужно сделать на самом деле, то его обратный синтез нужен для ответа на вопрос «Как?» это сделать. Первый заход на доработку бизнес-модели тоже помещается на схеме:
Это ещё не полноценная «бизнес-модель» (business model), а всего лишь расширенное представление потока создания пользы. При этом самые важные решения по развитию предприятия всё-таки отражаются в следующем рассуждении:
Предприятие должно обладать определёнными Способностями чтобы находить и эксплуатировать Потенциал в Сценариях Клиента. Для включения в Бизнес-контекст (цепочки или сети кооперации), важные Способности группируются в Организации, создающие рыночный Продукт (или Сервис). Предприятие может завести несколько Организаций для решения различных задач, в том числе и Стартапы для выявления Новых потенциалов и тестирования Новых продуктов.
В примере выше, завод по производству удобрений (Предприятие) уже занимается производством удобрений (Способность) и выпускает стандартные смеси (Продукт). Задумка руководства заключается в том, чтобы освоить новые технологии анализа почв (Способность) и научиться выпускать индивидуальные смеси (Новый продукт). Всё это очень похоже на рискованное вложение, поэтому имеет смысл протестировать рынок через MVP в виде «ручного подбора смесей» (Стартап). И уже потом принимать решение по инвестициям в развитие завода и расширение его продуктовой линейки.
Детальная проработка всей бизнес-модели значительно поменяет первоначальные представления о проекте, начинавшемся со слов «Нам нужна новая ERP-система».
В примере выше, нужно описать что изменяется в существующей бизнес-модели: концепция продаж (продолжаем отгружать удобрения как продукт или начинаем оказывать комплексный сервис повышения плодородности почв), работа с поставками (начинаем закупать сырьё под имеющиеся заказы или набираем сырьё оптом, под прогнозные объёмы), расширение деятельности (привлекаем подрядчиков для анализа состава почв или же создаём собственную экспертизу).
В рамках работ по реорганизации предприятия нужно проработать: изменение организационной структуры и процессов продаж, производства, снабжения, а также найм и обучение персонала, модернизацию производственных линий, маркетинговые мероприятия и многое другое, что выявится в ходе работы над бизнес-кейсом.
Наконец, детальная проработка ИТ-архитектуры наверняка принесёт задачи по модернизации систем PLM, CRM и SCM, по созданию новой информационной системы поддержки анализа почв (с технологией AI), синхронизации всех разделяемых данных и сквозных процессов, а также по модернизации ИТ-инфраструктуры.
Интермедия
Вот почему хорошо, если над ИТ-проектом действительно обнаружится программа организационного развития, направляемая инвестиционным портфелем. Это значит, что имеется проработанная стратегия, приоритеты развития, актуальная архитектура предприятия, прозрачный бизнес-кейс и чёткие требования к информационной системе.
Если же «прекрасное далёко» не спешит показываться на горизонте, то придётся шевелить собственным умом. Вот главные вопросы, проясняющие цель ИТ-проекта:
1. Роль информатизации и вопрос «Зачем?» решили развивать ИТ
2. Анализ потока пользы и вопрос «Что?» создаётся для клиента
3. Синтез бизнес-модели и вопрос «Как?» это делает предприятие
Конечно, в случае с коммерческой организацией, польза для клиента — ещё не повод вложиться в проект. Польза для владельца предприятия, она же «выгода», не менее важна. Но схемы рассуждения о выгоде те же самые, хотя и мысль разворачивается в обратную сторону: отталкиваясь от понимания пользы для клиента, создаётся полезный продукт, под который создаётся организация и встраивается в деловую среду (бизнесы не «строят с нуля», в них всегда «встраиваются») для получения выгоды.
К счастью, это уже совершенно другая история.
Продолжение следует…