О том, как сформировать стратегию, которая станет основой для принятия решений, какие факторы важно учитывать при ее создании, и что делать в постоянно меняющихся условиях, мы поговорили с Александром Долговым, CIO «Первой грузовой компании».
1241 просмотров
ИТ-стратегия – компас в работе ИТ-директора современной компании. Она определяет вектор, ключевые направления развития бизнеса при помощи технологий.
ПГК — высокотехнологичная компания в сфере услуг грузовой логистики. Регулярно запускает новые проекты и направления, совершенствует внутренние процессы, максимально используя потенциал ИТ-систем. Вместе с «КОРУС Консалтинг» ПГК сделала несколько проектов: систему расчета ставок, корпоративный портал на 3000 сотрудников.
Сначала вы работаете на стратегию, потом стратегия работает на вас
ИТ-стратегия позволяет четко сформулировать ответ на вопрос: какой должна быть компания через определенный горизонт времени, например — 5 лет. Она описывает базовые принципы и основы, на которых будет развиваться бизнес, и дает почву для принятия решений: какие проекты и зачем нужно делать, что получится в результате, и почему это важно.
Узкое место IT проекта: бизнес аналитик и проектный менеджер
Допустим, есть цель – на 25% повысить постоянную прибыль бизнеса через системные структурные изменения в управлении. Этого можно добиться за счет определенных шагов – для каждой компании они будут индивидуальны. Но базовые вещи везде одинаковы – нужно усилить клиентский сервис и повысить эффективность внутренних процессов через технологии. Эти задачи отражаются в ИТ-стратегии, и становится очевидно, какие продукты внедрять, когда, и зачем это нужно делать.
Самая большая польза стратегии в том, что в команде нет сомнений, что вы вместе делаете правильные вещи. При этом это рабочий документ – мы регулярно отслеживаем, на каком этапе находимся, не отклонились ли от курса. Всегда есть возможность поменять тактику: пересмотреть приоритеты, что-то приостановить или, наоборот, усилить и ускорить. Это абсолютно живая история, которая позволяет реально управлять ИТ-процессами.
ИТ-стретегия – не волшебная таблетка. Поможет не всем
Прежде чем создавать ИТ-стратегию, нужно определиться с общей стратегией компании. На ее основе подготовить документ, который позволит принимать решения быстро, логично и без сомнений в команде. Более того, ИТ-стратегию можно создать только тогда, когда у компании есть понимание, что она действительно нужна. Без этого получится не работающий документ, который помогает выстроить работу бизнеса, а еще одна красивая презентация.
Однако есть исключения – в некоторых компаниях из-за определенной корпоративной культуры создать ИТ-стратегию практически невозможно. Например, если акционеры или руководители напрямую решают, что нужно сделать, несмотря на планы развития. Если нет запроса на продумывание реализации долгосрочных целей, то пользоваться ИТ-стратегией в компании не будут.
Возможность создать действительно рабочую ИТ-стратегию во многом зависит от корпоративной культуры. Если в компании есть понимание важности такой работы, то она однозначно принесет результат. Например, у меня была возможность потратить пять месяцев на создание стратегии на три года вперед.
Как разработать IT стратегию?
Менеджмент понимает, что стратегия – это значимый, прикладной инструмент, а не просто лозунг. В этом документе зафиксированы обязательства ИТ-команды – цели, объем инвестиций в ИТ, измеримые показатели. Если в компании разделяют такой подход, то это самый эффективный путь развития ИТ.
Сначала взлетаем, потом ныряем: нужна «картина сверху» в взгляд в глубину
ИТ-стратегия – это конкретный документ, дорожная карта проектов с очень четким обоснованием того, зачем компании нужно их делать, и почему именно в такие сроки. В ней обязательно должны быть:
- Четкий образ компании через 3-5 лет в разрезе клиентского сервиса, ИТ-контура, команды и инструментов управления процессами.
- Ключевые направления программы ИТ-развития.
- Перечень конкретных проектов с обоснованием.
- Список целей в измеримых показателях.
Основное качество ИТ-стратегии — полнота. Поскольку стратегия создается на существенный горизонт времени – минимум на 3 года – в ней необходимо охватить все бизнес-области. Если забыть о каком-то направлении, развитие по нему остановится. Поэтому ключевые принципы успешной работы над стратегией – комплексно посмотреть на цели бизнеса, продумать целевую ИТ-архитектуру, структурировать все проекты, а затем уже «нырять» в детали и прописывать план реализации.
Не торопитесь делать отдельные стратегии по каждому из ИТ-направлений. Выделять в отдельный документ стоит масштабные истории, где требуется обособленное управление. Например, в ПГК выбрали шесть ключевых цифровых продуктов, в которых видели наибольший потенциал.
Требовалось обеспечить для них отдельные ИТ-ресурсы, чтобы быстро внедрять решения в операционную деятельность и затем трансформировать. Для этого был создан специальный документ, который позволил детализировать расчеты по финансам, срокам и планируемым показателям по каждому из шести продуктов. Это и стало основой для отдельной стратегии.
Очень важно обозначить ИТ-направления, которые помогут бизнесу сохранить устойчивость на любом уровне. ПГК удалось создать такую стратегию – принципы и цели, которые в ней заложены, позволяют компании оставаться лидером в любой конкурентной среде. На практике это достигается за счет эффективно выстроенных внутренних процессов и максимального качества клиентского сервиса.
Skin in the game или как работать с внешними ИТ-командами?
Точно стоит пригласить внешних ИТ-консультантов на старте, когда команда и ИТ-директор не знают, как методологически создавать и структурировать стратегию. Специалисты помогут освоить методику, декомпозировать цели, сформулировать вопросы, на которые нужно ответить, подберут инструментарий и дадут советы по дальнейшей работе. Если такая компетенция есть внутри компании, то партнеры все равно будут полезны — для того, чтобы реализовать значимый объем задач, собрать и обработать информацию, визуализировать и зафиксировать ее в материалах.
Надо помнить также, что после согласования стратегии наступит этап ее реализации – здесь тоже сложно обойтись без подрядчика. Важно, чтобы сторонняя ИТ-команда стала полноценным партнером в решении конкретных бизнес-задач компании, была заинтересована в достижении целевых показателей.
Поэтому основной принцип работы с внешним партнером – доверие и заинтересованность в результате с обеих сторон. Должна быть skin in the game у каждого: совместная работа на конкретные бизнес-результаты проекта. Это могут быть показатели логистических процессов, например, скорость отгрузки со склада в доставку, скорость самой доставки. В этом случае, это действительно партнерские отношения: команды в одной лодке, и ИТ-компания несет значимую долю риска и ответственности.
Важный момент – почему необходимо доверие с обеих сторон: не только заказчик доверяет партнеру, но и внешние консультанты понимают, что у клиента нет цели не заплатить за работу. Наоборот, бизнес готов платить больше, если будет общий результат, а значит и прибыль компании будет существенно выше.
«Черные лебеди» приплыли стаей: что делать С ИТ-стратегией сейчас?
Даже в текущей нестабильности стратегия – это то, на что можно опереться. Если изначально правильно заложить ИТ-направления, которые обеспечивают устойчивость бизнеса, они не потеряют актуальности в изменившихся условиях. Это еще одна ценность стратегии.
Конечно, в кризисное время ее нужно пересматривать в зависимости от ситуации и подгонять под действительность. В феврале 2022 года в ПГК переработали всю ИТ-стратегию. В первую очередь, то, что касается развития, потому что это влияет на будущий рост бизнеса. Когда западные компании ушли с рынка, в ПГК проанализировали, какие изменения ожидают компанию. Для этого рассмотрели каждый ИТ-проект через призму шести факторов влияния:
- Отключение от облачных решений. Прорабатываем план по замещению PaaS и IaaS.
- Невозможность покупать лицензии и новые продукты по on premise решениям. Считаем, по каким продуктам понадобятся дополнительные лицензии и когда.
- Смена стратегических партнеров. Определяем, какие партнеры исчезнут, что нужно срочно замещать, где искать новых.
- Отсутствие поддержки от вендоров. Планируем, как обеспечить поддержку уже работающих решений.
- Дефицит «железа». Анализируем, что нужно приобрести в срочном порядке.
- Изменения на рынке труда. Думаем, где теперь искать специалистов, какие управленческие методики лучше использовать.
Затем наложили все факторы на каждый проект и посмотрели, что поменялось в текущей ситуации. В зависимости от этого перестроили стратегию, «залатали» появившиеся дыры и создали подушку безопасности. При этом оказалось, что события не оказали на ИТ-стратегию значимого влияния, поэтому в компании ограничились тем, что за три месяца провели экстренные мероприятия для обеспечения непрерывности бизнеса, и оперативно отказались от использования облаков.
Самое важное
Если вы решились создать в компании ИТ-стратегию, важно помнить, что принципами, которые в ней заложены, вы будете пользоваться ежедневно. Стратегия – это одновременно и взгляд «сверху», и понимание деталей каждого проекта. В ней есть четкий план развития с программой, конкретными инициативами, сроками, оценкой объема инвестиций и их возврата. И главное – образ целевого результата, выраженный в измеримых величинах. Если у всех компаний будут детально продуманы и прописаны основные цели и принципы работы с ИТ, это сильно упростит работу, как внутри бизнеса, так и в целом на рынке.
Источник: vc.ru
Как найти узкие места в информационных системах
Для успешного проведения аудита главное – одинаковое понимание всеми заинтересованными сторонами целей и результатов проведения проверки.
Как связаны аудит и консалтинг
В чистом виде ИТ-аудит редко интересен компаниям. Узнать, что в бизнес-процессах или ИТ-инфраструктуре что-то идет не так, недостаточно. Надо понимать, что с этим делать. Поэтому, кроме предоставления результатов аудита и их интерпретации, заказчики хотят получить рекомендации о дальнейших действиях.
Аудитор может предложить как составление верхнеуровневого описания дальнейших действий, так и детальный план работ для реализации необходимых изменений в затрагиваемой аудитом области. Для аудитора, получившего в процессе обследования понимание о процессах в организации, также будет логичным предложить компании консалтинговые услуги или техническое сопровождение реализации предлагаемых изменений. Далеко не всегда ИТ-служба заказчика обладает компетенциями для планирования и запуска такого проекта. Например, она не может выделить достаточных внутренних ресурсов или не обладает компетенциями по формированию комплексных технических решений, включающих различное ПО и оборудование разных производителей, или не имеет необходимого опыта их эксплуатации и возможности провести соответствующее обучение. Опыт системных интеграторов показывает, что для большинства современных российских компаний привлечение внешнего партнера для реализации масштабных изменений в области ИТ является стратегией наименьшего риска.
Главное – управление рисками
Для успешного проведения аудита главное – одинаковое понимание всеми заинтересованными сторонами целей и результатов проведения проверки. Аудит может включать множество аспектов и объектов обследования – систему управления ИТ, цифровую зрелость бизнеса, компоненты инфраструктуры, проект создания информационной системы, затраты на ИТ, защиту сетевого контура, процессы поддержки устойчивости бизнеса, соответствие нормативной и регламентирующей документации требованиям и многое другое.
С точки зрения управления проектом аудита главный риск – отсутствие результата в поставленные сроки. Например, затягивание сроков проведения работ, незавершенность или неточность обследования, ошибочная интерпретация полученных данных.
Чтобы снизить вероятность проявления этих рисков, руководству необходимо быть непосредственно вовлеченным в проект, не только осуществлять мониторинг результатов, но и устранять препятствия. Бывают ситуации, когда сохранение незакрепленных документально, но действующих на высоком уровне договоренностей важнее возможных результатов формализованной проверки их эффективности, например, при использовании сложных схем лицензирования программных продуктов.
Информационные системы могут фактически находиться в собственности одного заинтересованного лица, но формально быть «размыты» по трем юридическим лицам. Так, доступ к системе для одной компании предоставляется как услуга второй компании, при этом в стоимость услуги включена аренда инфраструктуры у третьей компании.
То есть физически система представляет собой трехслойный пирог. Первый слой – вычислительные мощности третьей компании, передаваемые в аренду второй компании. Второй слой – инфраструктурное ПО, установленное на этих мощностях, лицензированное на третью компанию, но сдаваемое в аренду второй.
И наконец, третий слой – информационная система в виде серверов приложений и баз данных, развернутая поверх инфраструктурного ПО и лицензированная на вторую компанию. Таким образом, весь этот «пирог» оплачивает первая компания, покупая услугу доступа у второй. Механизм формирования стоимости такой аренды не всегда понятен внешнему наблюдателю и может казаться экономически неэффективным для первой компании. При этом вся сложность продиктована, например, необходимостью прозрачного и динамичного формирования затрат на лицензирование по количеству рабочих мест, которое сильно зависит от сезонности в ряде случаев.
Как аудит помогает находить узкие места в ИС
Независимо от типа аудита рекомендуется его проводить по лучшим стандартам и практикам. Среди них – подход ITAF, разработанный международной организацией аудита информационных систем ISACA (сейчас этот подход является одним из разделов их структурированной методологии по управлению ИТ в организациях – COBIT версии 2019).
В соответствии с этим подходом проект аудита включает такие этапы, как управление рисками, планирование аудита, проведение аудита, выработка рекомендаций и подготовка отчета. Перед непосредственным сбором информации обычно проводят разработку методов сбора и обработки информации, которая позволяет ограничить персонал аудируемой компании от лишних волнений и заполнений ненужных форм.
Перед началом технического аудита системы необходимо заранее согласовать применяемые процедуры и область данных, которая может быть затронута проверкой. Существующие средства анализа ИС позволяют проводить как проверку безопасности, так и тестирование, имитирующее работу множества пользователей в системе.
Подобные проверки позволяют найти узкие места в инфраструктуре или, наоборот, в программных элементах системы. Если какие-то компоненты не выдерживают нагрузки, выполняется дополнительный анализ этого участка.
В зависимости от поведения системы может проводиться анализ настроек оборудования и middleware, а также изучение кода на наличие неоптимальных алгоритмов работы с данными или компонентами системы. Важно помнить, что технический аудит должен учитывать соответствие уровня доступа к бизнес-критичным или защищаемым данным третьих лиц не только сотрудников компании, но и аудитора.
Помимо самой системы и ее компонентов анализируется история внесения изменений в программный код, охват проекта и архитектура системы. После анализа информации проводятся необходимые оценка и выработка рекомендаций. При использовании такого подхода аудит сможет выявить не только последствия вносимых в систему изменений, но и причину их внесения.
Часто в ходе аудита выясняется, что влияние конкретных лиц на процессы разработки системы привело к несоблюдению намеченного графика и последующему отставанию в реализации значимых этапов. Изначальная потребность в определенной проверке может привести к формированию собственных компетенций по аудиту на постоянной основе или к привлечению внешних сертифицированных аудиторов на проект. Например, некоторые компании создают подразделения внутреннего аудита, которые разрабатывают и отслеживают работу системы автоматизированных контролей, встраиваемых в системы исполнения бизнес-процессов. Внутренние аудиторы контролируют как работу информационных систем, так и исполнение бизнес-процессов, выявляя узкие места и возможности оптимизации.
Все ходы записаны: анализ хода проекта
При проведении анализа функциональных возможностей информационной системы производится сопоставление изначальных требований, заявленных в техническом задании или зафиксированных в бэклоге системы управления разработкой и реализованных функциональных возможностей. Обязательно должны быть учтены все вносимые изменения – кто их внес, кто именно согласовал, как они повлияли на сроки и бюджет проекта.
Как правило, потребность в таком аудите возникает, когда проект не приносит ожидаемых результатов к заявленному сроку или значимому событию. В данном случае не важна парадигма, в которой система создается, будь то каскадный или гибкий подход, главное – соответствие требованиям заказчика.
Даже проект гибкой разработки может «свернуть не в ту сторону», если, например, команда пошла на поводу у наиболее влиятельных, «громких» сотрудников, которые при этом не отвечают за весь ход проекта, а заинтересованы только в выполнении своей части. Если аудит выявляет подобное влияние, это сигнал для вышестоящего руководства – проекту потребуется гораздо больший контроль, хотя бы на этапе пересмотра его охвата (scope). Разрыв между требованиями и реализованными функциями может нарастать к сроку завершения проекта. Следует помнить, что реализация изменения, вносимого в уже запущенный проект на поздних сроках, обойдется дорого. Именно поэтому все значимые изменения должны выноситься на обсуждение ответственных лиц, а их решения – быть отражены в протоколе.
Причины возникновения «разрывов»
Причинами изменений, не входивших в план заказчика, могут стать не только влияние отдельных ответственных лиц, но и инциденты в самой проектной команде. Когда речь идет о крупном проекте, к работе над ним могут подключать сразу несколько команд разработки.
Если архитектор не контролирует реализацию, а руководитель не оркеструет взаимодействие команд, могут возникать инциденты: неработоспособность системы в ходе неожиданного для многих penetration теста или проведение нагрузочного тестирования без согласованного ранее расписания может заблокировать ввод в эксплуатацию нового функционального блока и так далее. Особенного внимания требуют ситуации, когда система обеспечения непрерывности, регламенты резервного копирования и регламенты восстановления работоспособности еще не проработаны, а в эксплуатации уже находятся «боевые» базы данных. Могут возникать и технические инциденты. Например, в 2019 году в Москве из-за короткого замыкания в системе кондиционирования и возникшего в связи с ним пожара в ЦОД DataLine (Tier III) более чем на 15 часов была парализована работа многих публичных высоконагруженных сервисов. А еще менеджер продукта может «набросать» макет в no-code-платформе и требовать его интеграции в систему, игнорируя правила безопасности, технические ограничения и здравый смысл.
Затраты на инфраструктуру
Выбор модели затрат на эксплуатацию ИС зависит от интересов бизнеса к капитализации и перспективы развития этой системы. Иногда системы лучше размещать только на собственном оборудовании заказчика, например, защищенных контурах государственных информационных систем.
Или, напротив, на стороне провайдера – брокерские компании, работающие с иностранными биржами, предпочитают размещаться на наиболее «близких» к ним площадках (близость измеряется как географически, так и числом промежуточных сетевых узлов), ведь для эффективного использования торговых роботов могут быть критичны миллисекунды задержки сетевого трафика. В любом случае, выбирая услуги провайдера или собственное оборудование, надо учитывать план развития системы: историческое изменение нагрузки, возникновение пиковых моментов, даже изменения в бизнесе, которые могут увеличить число активных пользователей (или подключаемых умных устройств) в разы.
Иногда возникают сомнения, как правильно оценить влияние тех или иных факторов на выбор инфраструктурной модели или модели затрат, или на проведение такого исследования нет времени. Иногда проект настолько крупный и важный для бизнеса, что для принятия окончательного решения о векторе развития нужна внешняя экспертиза. Проект развития ИС может выполняться по плану, но даже при этом результаты не всегда соответствуют ожиданиям. В таких случаях можно обратиться к лучшим практикам или кейсам других компаний или за профильным аудитом и консалтингом.
Источник: www.it-world.ru
Быстрое ИТ-стратегирование: начинаем автоматизацию правильно
«Болит автоматизация по всем процессам, не знаем, за что браться», «Мы не до конца понимаем, зачем нужен этот ИТ-проект», «Сменился главный айтишник, и срочно нужен новый план», «ИТ-стратегия нужна была вчера, а быстрые победы – уже завтра», «Уже и так целый зоопарк систем, куда еще?» – если вы задаетесь этими вопросами, предположу, что работающей долгосрочной ИТ-стратегии в вашей компании нет. Меня зовут Светлана, я – бизнес-архитектор: когда у заказчика есть боль в ИТ-области, но непонятно, что с ней делать – отправляют ко мне.
В целом ситуация понятна, и обоснована она чаще всего нынешними условиями рынка. Совсем недавно ИТ-стратегии создавались на 10-15 лет (а для некоторых крупных компаний такие стратегии и по сей день актуальны, но трансформировались), позже – редко стали превышать 5-летний, а потом и 3-х летний горизонт планирования. Сейчас самая востребованная стратегия – на полгода. По сути, стратегия из редкой деятельности превращается в операционную, а инструментов для ее формирования по типу известной всем CRM для продаж рынок не даёт.
Получаем следующее: когда планируется нечто долгосрочное и основательное – можно обратиться к профессиональным консалтерам. А что делать, если вопросы решать надо «здесь и сейчас», что предпринимать – непонятно, а потенциальные исполнители встают в позу: «скажите точно, что нам делать»? Все эти явления (а также нехватка решений на рынке) подтолкнули меня на создание собственной методики быстрого стратегирования – на основе своего опыта работы в ИТ и практик известного бизнес-тренера.
Найти и распознать
Чтобы все ваши усилия по быстрому ИТ-стратегированию, пусть даже небольшие, принесли реальную пользу в виде успешных проектов, первым делом нужно проанализировать прошлый опыт в рамках работ по автоматизации – собственных или на примере кейсов известных компаний. Так вы с наибольшей вероятностью сможете избежать ошибки в будущем.
Эта причина кроется в связке «боль->результат->эффект->конечная цель». И именно эффект все упускают из виду, хотя он является как раз тем самым KPI любого проекта по автоматизации. Если не оцифрованы KPI, вы играете в рулетку win/fail без права на третий вариант.
Как это работает на практике
Посмотрите описание любого проекта автоматизации. Вы увидите оцифрованные текстовые описания: какие имеем «боли», что нужно для их решения, «упаковку» – название проекта.
Но как вы поймете, а далее докажете, что достигли целей и что вложения были оправданы? Только в том случае, если вы проверили эффект от результатов проекта. Ведь, к примеру, смысл не в наличии лодки для плавания по горному озеру, а в возможности путешествовать по нему. И здесь вам нужен не просто факт возможности путешествия, а путешествия «с ветерком» – ведь если не с ветерком, а в поту на веслах, зачем вам вообще эта лодка? Так и в жизни: заказчики получают свои ИТ-проекты – один, второй, пятый, а до целей так и не доходят.
Мой вариант – определиться с тем, что нужно, а затем закрепить сразу всю связку «боль->результат->эффект->конечная цель», чтобы далее уже до конца проекта отслеживать не наличие «лодки», а возможность «плавать с ветерком». И поверьте, лицо, не обладающее ИТ-компетенциями, также без труда сможет разобраться в таком Техническом задании: достаточно взять эту связку и спросить подрядчика: «А где именно написано, что такое «с ветерком», и как будем измерять результат?» И все: «приехал» подрядчик, если он не профессионал.
Ниже приведу 4 основных этапа успешной автоматизации:
- Провести само ИТ-стратегирование («что?»);
- Подобрать решения («как?»);
- Сделать анализ ключевых целей и задач проекта («зачем?»);
- Сформировать KPI проекта («как проверить успех?»).
Шаг 1. ИТ-стратегирование с представителями бизнеса
Этот шаг позволит сформировать ожидания стейкхолдеров от ИТ и получить точные ответы на вопросы:
- Какие конкретно «боли» бизнес-заказчики хотят решить с помощью ИТ?
- Какой результат автоматизации предполагается?
- Какой эффект должен обеспечить результат автоматизации, чтобы точно устранить боль?
- К какой цели приведет эффект, полученный от результата?
Люди
Ищете фасилитатора и закрываете его на два часа с полным составом руководителей высшего звена вашей компании.
Процессы
Мозговой штурм или «сессия дизайн-мышления». Стикерами на доске заполняете таблицу из 5-х столбцов (автор/для кого актуально, боль, результат, эффект, цель).
Технологии
- «Чистый лист»
Забываем все, что говорили, писали, думали и с чистого листа заполняем доску. Каждый руководитель высшего звена печатными буквами пишет на стикере и приклеивает в таблицу «боли», «результаты», «эффекты» и «целы». После завершения процесса озвучивает написанное, а если у коллег есть сходное описание, стикеры клеятся друг на друга. Важно: написанное только озвучивается, но не обсуждается и не критикуется. - Использование «правильных» вопросов» и правила «пяти зачем»
«Что именно болит?» (боль), «А как хотелось бы, чтобы было?» (результат), «А что это вам даст?» (эффект), «К чему в конечном итоге приведет?». Чтобы точно разобраться и не запутаться в эффектах и целях, спросите себя 5 раз про результат: «А это зачем?». Остановитесь, если речь зашла про личные ценности или деньги. - Группировка заинтересованных сторон
Разделите всех авторов/стейкхолдеров на 4 категории: «внешние индивидуальные», «внешние групповые», «внутренние индивидуальные», «внутренние групповые». Внешние стейкхолдеры – по отношению к сидящим на штурме. Групповые – к примеру, отдел. Индивидуальные – главный инженер. И решите, кому помочь сейчас важнее всего. Интересы остальных отложите на потом, но важно честно об этом договориться и не забыть. - Рейтингование запросов в таблице
Обратите внимание, что проводится он по степени соответствия или степени влияния обсуждаемых запросов на ваши цели. Выбирайте и точно озвучивайте за что голосовать. Если строк меньше 30, пусть каждый участник напишет на каждом стикере 3-2-1. Если строк больше 30, используйте факторный анализ: каждый участник по каждой строке ставит значения «-9,-6,-3,0,3,6,9», а затем выводится среднее значение всех оценок.
- Опросы
Для мидл-менеджмента используйте опросники: пусть заполнят самостоятельно такую же таблицу. Спросите их требования или пожелания к необходимой им информации, используемой для принятия управленческих решений. Внесите в таблицу ниже требования или пожелания к необходимой вам информации, используемой для принятия управленческих решений. По каждому пункту ответьте на три вопроса и определите подходящую категорию проблемы, например:
- В системе недостаточно данных или их надо вносить руками.
- Данные не объединяются автоматически.
- Нет удобных витрин, дашбордов, онлайн-отчетов.
- Информация содержит грамматические ошибки.
- Поиск данных очень затруднителен.
На выходе получите «портянку» потребностей бизнеса с приоритетами.
На этом самая сложная и важная часть – бизнесовая – завершена. Откладываем в сторону эмоциональных заказчиков, берем в руки раздел «Результаты» и одного грамотного айтишника, чтобы на следующем шаге найти технические решения для получения результатов. Часто бывает, что заказчик думает, что знает решение, а это не совсем так. На деле запрос «напишите нам информационно-поисковую систему» может решиться простым внедрением BI-решения.
Шаг 2. Подбор/поиск технических решений для получения требуемых результатов
Люди
Руководитель ИТ/ Enterprise Architect/Бизнес-архитектор + авторы запросов
Процессы
- Для каждого запроса определите технологический стрим (здесь быть ИТ-шником не нужно, т.к. на самом деле это просто этап автоматизации, на котором вы сейчас находитесь в этом запросе):
01 – данных в информационной системе недостаточно;
02 – данные есть, но информация некорректна/неактуальна,
03 – данных в каждой системе достаточно, их надо «вытащить» и собрать статистику,
04 – данных в каждой системе достаточно, статистика собирается, нужны прогнозы, т.е. уже более умная аналитика,
05 – надо посчитать, как принятое решение повлияет на всю систему бизнеса в целом: применить систему имитационного моделирования,
06 – готовы доверять решение искусственному интеллекту: пора внедрять нейронные сети и роботизацию. - Сгруппируйте запросы по стримам.
- Отдайте проверенному айтишнику – он подберет решения. Из моего опыта: группировка запросов по текущим этапам автоматизации расскажет ИТ-архитектору о состоянии ИТ в вашей компании быстрее, чем самое быстрое, крутое и дорогое обследование. Он сможет задать «правильные вопросы» и системно подойти к выбору комплекса технических решений, каждое из которых закроет сразу целый ряд потребностей. Потребности и их приоритеты понятны, решения – тоже. Узнать по рынку порядок стоимости решений – недолго. Определитесь с составом проекта/ов и ни в коем случае не останавливайтесь на этом шаге. Именно так часто случается опыт «неуспешной автоматизации»: зря потраченных денег и нервов. Потратьте еще совсем немного времени и получите ответ еще на один вопрос: «Как будем проверять успех?»
Шаг 3. Формирование KPI/OKR проекта
Люди
Фасилитатор с навыками аналитического мышления + участники шага №1.
Процессы
Разработка реперных точек и проработка показателей успеха проекта.
Технологии
Если потребности всех стейкхолдеров удовлетворены – это и есть успех проекта.
- Обратная декомпозиция Группируйте все боли по сходным результатам, результаты – по сходным эффектам, эффекты, соответственно, – по сходным целям. Получится дерево.
- Проверьте это дерево вместе с участниками ИТ-стратегирования в обратном порядке:
1. «А сможете ли вы считать, что цель достигнута, если сбудутся все указанные в схеме эффекты?».
2. «А скажете ли вы, что эффект достигнут, если сбудутся все указанные результаты? Как доказать?» и на этом моменте уточните формулировки эффектов. 3. «А эти результаты, вот в такой формулировке, в сумме точно смогут достигнуть эффекта?». По опыту: надо будет переформулировать (коллективно).
Получится схема под названием «Достижение целевых показателей деятельности компании с помощью информационных технологий».
Самое важное и самое интересное: каждого участника ИТ-стратегирования по каждому эффекту надо спросить, как они определят, что эффект достигнут. Эффект не обязательно надо измерять количественно, можно и качественно (ответом на вопрос «да»/«нет»). Все выше было сделано ради этого момента: если нет точных ответов – нет смысла запускать проект.
Осталось малое – зафиксировать все в документе и согласовать с бизнесом.
Шаг 4. Оцифровать анализ ключевых целей и задач проекта
Для названия документа мы придумали акроним «АКЦИЗ» – анализ ключевых целей и задач проекта. Опытным путем определили документу максимальный размер в 6 листов, из которых информация на первых трех должна быть достаточной для принятия решения руководством.
Люди
Любой сотрудник с навыками аналитика и топ-менеджмент – для согласования.
Процессы
Оформить все пункты выше в один документ, чтобы лица, принимающие решение, мог на нем окончательно договориться.
Технологии
Важно, чтобы формат документа точно отвечал на вопросы:
- «В целом что сейчас требуется организации?» (индивидуальный диагноз)
- «Кому и какие ценности это даст?»
- «В каком именно виде эти «они» свои ценности получат и что для этого требуется?».
Я в АКЦИЗе использую трехмерную матрицу ценностей (эффектов) для всех участников в разрезе конкретных результатов. Стейкхолдерам достаточно найти «свою колонку», чтобы увидеть что именно им обещает этот проект.
Выводы
Успех результатов ИТ-стратегии, в конечном счете, всегда определяется топ-менеджерами компании, которые решили потратить деньги на проект и мы с вами рассмотрели короткий путь от идеи до запуска успешных ИТ-проектов.
Выше мы прошли путь помощи заказчику в формировании его потребности, вместо бесконечных вопросов «а что вам надо?»: и этот подход применим ко многим проектам, не только в сфере ИТ. Определяйтесь с «хотелками», договаривайтесь внутри, а потом точно контролируйте эффекты – вот и весь секрет.
- ит-стратегия
- автоматизация
- автоматизация бизнеса
- Блог компании ICL Services
- IT-инфраструктура
- Бизнес-модели
- IT-компании
Источник: habr.com
