Если правила неясны, а приказы непонятны, это вина военачальника. Если же они ясны, но не исполняются, это вина командиров.
В предыдущих главах мы говорили о проектах, в которых процессы играли самостоятельную роль, были главным объектом приложения усилий. В то же время не реже, если не чаще, процессные проекты возникают как вспомогательные по смыслу, хотя и очень объемные по размаху работ. Генезис таких проектов – управленческий. Реализуется либо организационная задача – совершенствование или внедрение какой-то управленческой подсистемы или корневой системы менеджмента. Либо мы ищем варианты решения неочевидной бизнес-задачи, которые так или иначе найдут отражение в процессах. Рассмотрим такого рода проекты.
2.4.1. Проекты реализации системных решений в процессах
Примеры таких проектов:
• совершенствование системы документооборота;
• внедрение системы управления операционными рисками;
• совершенствование подсистемы управления каким-либо объектом, имеющим свой кросс-процессный жизненный цикл (рабочий парк цистерн, регламентная база, оборудование различного типа, активы и т. п.);
• внедрение системы менеджмента (бережливое производство, системы менеджмента качества, «Шесть сигм» и т. п.);
• подготовка предприятия к сертификации по стандартам ISO;
• трансформация процессов после слияния или поглощения компаний
и так далее.
Хотя у каждого из перечисленных проектов есть свои нюансы, их объединяет общий подход. Прежде всего должен быть выполнен Этап 1. Разработка системного решения. Прорабатываются общий замысел, концепция и системные управленческие детали, которые впоследствии должны будут воплотиться в организационные решения, методики, положения, а также реализоваться в процессах.
Например, если мы говорим о совершенствовании документооборота, то проработка системного решения заключается в систематизации и классификации документов, а также проектировании жизненного цикла различных групп документов. В частности, может быть предусмотрено подписание документов электронным образом, с использованием электронной подписи, разграничение прав доступа и тому подобные решения. Аналогичный подход используется в большинстве проектов, касающихся объектов или активов с собственным кросс-процессным жизненным циклом.
Пример
В этом году я консультировал большую организацию, которая занялась внедрением процессного подхода и довольно быстро начала упираться в сложности с постановкой задачи на проекты трансформации процессов. С одной стороны, надо было продемонстрировать эффекты применения процессного управления. С другой – частные задачи, вытекающие из проблем конкретного процесса в рамках отдельного филиала или подразделения организации, выглядели для этого недостаточно масштабными и амбициозными. В то же время организация занималась существенным реформированием собственной структуры, в фокусе которого были необходимость унификации и стандартизации отдельных процессов и процедур, а также масштабное перераспределение задач, функций, полномочий и ответственности, которые в совокупности должны были привести к серьезной экономии и повышению эффективности и качества деятельности. Поэтому довольно очевидной рекомендацией (впрочем, как раз позволившей выйти из тупика) было предложение отбирать процессы, наиболее критические в целом для организации и подвергающиеся наибольшей трансформации именно в результате реформы структуры, и в первую очередь ставить перед ними задачу соответствовать замыслу реформы. Как задачи второго уровня важности могла быть добавлена необходимость улучшить процессы по тем или иным характеристикам. Но основные усилия должны быть направлены на воплощение в процессах системных решений, связанных с общей реформой.
После того как сформулирован замысел реформы, можно и нужно переходить к ее реализации через процессы. С точки зрения общего проектного плана далее следует не этап, а, скорее, некоторая совокупность подпроектов, причем, вполне возможно, взаимосвязанных. Назовем этот шаг проекта Фазой 2.Подпроекты трансформации процессов. Каждый из подпроектов фазы является проектом трансформации того или иного процесса или группы процессов. Процессный охват, используемый метод (инжиниринг, реинжиниринг, совершенствование) и формулировки задач на трансформацию определяются замыслом реформы, разработанным на этапе 1.
Завершается проект Этапом 3. Разработка и реализация Плана внедрения системного решения. Технически он может выполняться и параллельно фазе 2. Кроме того, он может включать в себя соответствующие этапы из подпроектов трансформации процессов – и то и другое вполне допустимо и разумно.
Упражнение
Участвовали ли вы в проектах реализации системных решений? Какой план проекта использовался?
2.4.2. Процессные проекты в решении бизнес-задач
Решение бизнес-задач отличается от проектов реализации системных решений высокой степенью неопределенности на начальном этапе. У нас нет разработанного и структурированного (в части методологии или локализации в системе управления или в процессах) решения, а есть просто вопрос. Например, мы решаем бизнес-задачу:
• формирования конкурентных преимуществ через оптимизацию продуктовой линейки;
• выхода на новые географические рынки посредством развития филиальной сети и системы дистрибуции;
• радикального увеличения продаж;
• увеличения доли рынка.
И тому подобное.
В таких задачах мы изначально не знаем, какие области бизнеса придется реформировать, какие подсистемы управления и процессы будут охвачены. Дело в том, что сначала нам понадобятся идеи, а потом их проработка и детализация. И только на третьем шаге мы сможем перейти к процессной трансформации.
Таким образом, имеем следующий проектный план.
Этап 1. Разработка замысла решения бизнес-задачи. На этом этапе рассматриваются различные идеи и подходы, они проходят предварительную оценку, позволяющую выбрать какой-либо путь. В значительной степени этап требует креатива. Он должен дать укрупненный ответ на вопросы: как решить задачу и что для этого должно быть сделано? По его окончании определяются области системы управления и деятельности, которые должны быть проработаны детально для реализации выбранной идеи.
Этап 2. Детализация выбранного замысла, проектирование решения бизнес-задачи. На этом этапе задуманное укрупненное решение прорабатывается в деталях, проектируются отдельные правила, частности, алгоритмы и т. п., отвечающие на вопрос, как именно должно быть сделано то, что определил этап 1. На выходе этого этапа будут, в частности, конкретные процессы и задачи к ним для трансформации.
Фаза 3. Подпроекты трансформации процессов. Далее мы реализуем проекты, в которых процессы меняются для того, чтобы соответствовать замыслу решения бизнес-задачи.
Этап 4.Разработка и реализация Плана внедрения решения бизнес-задачи. Как и в предыдущем параграфе, этот этап может выполняться параллельно фазе 3. Кроме того, он может включать в себя соответствующие этапы (разработки планов и внедрения) из подпроектов трансформации процессов.
Упражнение
Участвовали ли вы в проектах решения бизнес-задач? Какие задачи решались? Как трансформировались процессы под выбранный замысел?
2.5. Автоматизация процессов
Это верно, что автоматизация создает новые области занятости. Теперь требуется гораздо больше людей для исправления ошибок.
2.5.1. О стратегии автоматизации и ее связи с процессами
Автоматизация бизнеса – тема обширная и многоаспектная. Я здесь ни в коем случае не хочу на нее замахиваться ☺. Мы поговорим о планах проектов автоматизации с фокусом на том, как они взаимодействуют с процессами.
Прежде чем обсуждать собственно план, надо обратить внимание на ряд моментов.
Сейчас сам термин «автоматизация» может означать самые разные вещи. Это может быть как полномасштабное, на несколько лет, весьма дорогостоящее внедрение «большой» ERP-системы34, реализуемое в виде крупного проекта с привлечением вендора35 и компаний-подрядчиков, так и настройка какой-то процедуры штатным сотрудником почти мимоходом, за несколько дней в системе класса BPMS36.
К сожалению, в большинстве компаний автоматизация представляет собой хаотичные и слабоосмысленные действия, которые приводят к тому, что сотрудники вынуждены работать во множестве систем, толком не внедренных, использующихся на малую долю своей функциональности, часто пересекающихся по возможностям и «накрываемым» областям, дублирующих друг друга, не состыкованных по данным и демонстрирующих прочие ужасы. При этом внедрение и поддержание этих систем – недешевое удовольствие. Казалось бы, это должно подталкивать к осмысленным действиям. Но на практике это не так. Нередко такое парадоксальное положение дел объясняется тем, что предприниматели доверяют эту сферу так называемым «айтишникам», причем самого разного уровня, а сами в нее не погружаются, считая тему сложной. Специалисты же часто оказываются «специалистами» в кавычках, неспособными даже понять, какую именно задачу должны решать. И сбиваются на внедрение любимых или просто уже освоенных систем, с легкостью покидая работодателя, оставляя своему преемнику в наследство полувнедренное и недокументированное решение. Новый «специалист» дезавуирует работу предшественника и продвигает свою облюбованную систему. И так может продолжаться годами. Но даже если ИТ-директор – давний сотрудник компании, результаты его работы по автоматизации нередко мало отличаются от описанных. Объясняется это тем, что никто не пытался воспринимать автоматизацию бизнеса как задачу, требующую планирования на стратегическом горизонте.
Конкретные проекты автоматизации должны вписываться в выбранную компанией Стратегию развития ИТ. Ее качественная разработка – во многих случаях весьма непростая задача. Например, очень важно, хотя и непросто, отстроиться от влияния политических игр, моды, досужих суждений про «все пропало, надо все автоматизировать» и т. п. Надо учесть множество факторов и сделать выбор на многих развилках в условиях бурного развития самих технологий и различных решений, пытаясь видеть перспективу и будущее. То есть Стратегия должна содержать целевое состояние ИТ в стратегической перспективе (и по пути к ней) и те самые проекты, которые это состояние создадут. Стратегия развития ИТ – функциональная в составе Стратегии бизнеса. Причем способная как стать основой конкурентных преимуществ, так и трансформировать саму бизнес-модель.
В качестве примера приведу небольшой список факторов, нюансов и развилок, с которыми надо управиться.
• Какого рода решения должны лежать в основе стратегии: комплексные глобальные системы типа ERP, накрывающие всю или почти всю «поляну» бизнеса? Или локальные решения, лучшие для конкретных функций или задач? Те, которые придется «сшивать» между собой? Крупные решения дороги и трудоемки для внедрения, их непросто заменить, если понадобится (вендор ушел с рынка или перестал поддерживать решение, например). С лоскутной автоматизацией проще в части смены решений, но их очень сложно стыковать и поддерживать (например, зачастую нужны спецы на каждую из систем: апгрейд, развитие функциональности и интеграция с другими системами, управление пользователями и доступом и пр.). Такой подход чреват возникновением со временем «зоопарка» систем. Возможно, стоит оценивать промежуточный вариант: иметь некоторую универсальную систему и ограниченное число специализированных решений в основных областях деятельности.
ИТ-хозяйство еще и весьма разнообразно: бизнесу нужен софт разного уровня и назначения. Надо поддерживать и рабочие места разных типов, и различные корпоративные функции, скажем, планово-учетную, причем с разных точек зрения: управленческой, финансовой, бухгалтерской и налоговой. Автоматизация документооборота, управления по целям и KPI, управления проектами, взаимоотношениями с клиентами (CRM), системы класса ERP и MES, системы и решения, обеспечивающие безопасность, и др. – далеко не полный перечень автоматизированных систем управления, которые способны давать ощутимый эффект для бизнеса. И они должны найти свое место в Стратегии развития ИТ.
• Существенный, хотя и скучный пласт нюансов связан с техническими требованиями, параметрами и совместимостями. Их игнорирование чревато необходимостью нехилых вложений впоследствии.
• Cтратегия должна разумно распорядиться сегодняшними и перспективными требованиями к системам, учесть как их изменение в соответствии с динамикой рынка, так и изменение размеров самой компании. Дилемма такова: текущие требования хорошо известны, но уже завтра начнут «плыть». А перспективные требования на стратегический горизонт мы можем только прогнозировать и планировать, но предсказать с высокой точностью – вряд ли. Слишком много факторов влияния, много рисков, да и «черные лебеди» встречаются. Но принимать решения надо уже сегодня, поэтому так или иначе выбор придется делать.
Технологии развиваются с ошеломляющей скоростью и неважной прогнозируемостью. Перспектива вложиться в систему, которая завтра окажется устаревшей, причем критически, – так себе. Поэтому (кстати, полезно во всех смыслах) нужно следить за технологическими новостями и прогнозами и стараться примерять их на свой бизнес, в том числе на область ИТ.
• Надо хорошо представлять себе всю «поляну» рисков, способных повлиять на ИТ-архитектуру бизнеса и ее перспективы. Эти риски самого разного свойства: начиная от политических, эпидемических, вообще разнообразных глобальных, включая всевозможные рыночные, в первую очередь отраслевые, и заканчивая (но не ограничиваясь ☺) рисками вендоров и компаний ИТ-индустрии. Уход/продажа/банкротство/смена курса разработчика чувствительной для компании системы бьет по бизнесу весьма ощутимо.
И так далее, и тому подобное.
Для большинства компаний наиболее объемные проекты автоматизации связаны с бизнес-процессами, поскольку именно автоматизация деятельности – ключевое направление автоматизации бизнеса вообще.
Стратегия развития ИТ должна выражаться в том числе в Дорожной карте проектов автоматизации. И значительная часть этой активности будет связана с процессами.
Упражнение
Есть ли в вашей организации Стратегия и Дорожная карта проектов автоматизации? Предусмотрена ли там автоматизация процессов?
2.5.2. О выборе ИТ-решения и подрядчика
Когда мы укрупненно определили в Стратегии развития ИТ, какое решение (и соответственно проект внедрения) нас интересует, переходим к формулированию требований. Чтобы затем выбрать конкретное решение и подрядчика, который поможет нам реализовать проект.
Требования состоят из различных разделов. Вот самые важные из них.
Функциональные требования. К ним относят задачи и функции, которые система должна выполнять. Например, хранение и извлечение конкретных данных, формирование по ним аналитических срезов и отчетности и т. п.
Организационный объем. Это подразделения, деятельность которых полностью или частично подлежит охвату системой. Все чаще эта группа требований заменяется процессным объемом, что гораздо адекватнее выражает интерес бизнеса. То есть это та часть процессов организации, которая должна быть охвачена системой.
Технические требования, которые включают требования к производительности (скорость работы системы, масштабируемость, надежность, доступность и т. п.) и безопасности (защита от несанкционированного доступа, кражи или потери данных). Система должна быть способна справляться с нагрузкой при максимальной интенсивности процессов, входящих в процессный объем.
Требования интеграции и совместимости с существующими системами, базами данных и приложениями организации (точнее, с аппаратно-программными комплексами).
Эргономические требования. Система должна быть удобной и интуитивно понятной сотрудникам.
Требования к потенциалу развития системы. Она должна иметь возможность адаптироваться к изменяющимся потребностям и процессам бизнеса с течением времени. Это означает возможность настраивать или модифицировать систему по мере необходимости, не требуя полной перестройки.
Требования соответствия правовым и отраслевым нормам и стандартам, куда могут быть отнесены законы о защите данных, отраслевые правила и т. п.
• Ограничения по стоимости и срокам. Их формулирование позволяет сузить круг рассматриваемых решений и предложений подрядчиков.
Важно тщательно оценить и расставить приоритеты этих требований, чтобы гарантировать, что система соответствует потребностям организации и обеспечивает желаемые возможности и преимущества. Приоритеты могут присваиваться в виде стоп-факторов (обязательных для соблюдения в любом случае, когда не удовлетворяющие им решения просто не рассматриваются) или в виде весов, что позволит в дальнейшем использовать комплексные оценки различных ИТ-решений при их отборе37.
Отсутствие формализованных требований, впрочем, нередкий случай. Оправдания у компаний, которые ищут подрядчика на такой проект, – обычно что-то из этого списка:
• у нас нет времени на бумажки, пусть нам расскажут, как оно должно быть: мы ведь наняли профессионалов, они все знают;
• тут все просто, нечего писать;
• мы не можем составить требования, мы непрофессионалы.
И тому подобное.
Такая инфантильность – крайне рискованный подход: организация отдает очень важную сферу своего бизнеса в руки стороннему подрядчику, отказываясь от контроля и ответственности, что чревато большими проблемами и разочарованиями.
Бывают, однако, и другие крайности, когда требования настолько фантастические и оторванные от реальности, «придуманные», что на рынке не находится решений, способных им удовлетворить.
Имея требования к ИТ-решению, мы можем перейти к его выбору. Причем, помимо систем, имеющихся на рынке, иногда стоит (при наличии соответствующих компетенций) рассматривать и возможности самостоятельной разработки приложений.
В первую очередь необходимо докрутить сформулированные требования до критериев выбора. Какие факторы и с каким весом должны участвовать в выборе решения? Какие требования являются обязательными (так называемые стоп-факторы)?
В частности, к критериям выбора всегда относится стоимость, которая в требованиях, как правило, отсутствует. Причем необходимо оценивать так называемую совокупную стоимость владения38, то есть учитывать стоимость лицензий (как первоначальные, так и последующие платежи), внедрения (в том числе расходы на обучение сотрудников и привлечение подрядчиков) и обслуживания ИТ-системы.
Иногда рекомендуют оценивать также окупаемость инвестиций (ROI) системы. Но на практике в большинстве случаев это гадание на кофейной гуще и по этой причине критерием выбора служить не может.
Дальнейшая процедура по существу (за исключением самого перечня требований) не отличается от описанной в первой книге серии39. Необходимо:
• составить long list рассматриваемых систем и решений, удовлетворяющих условиям стоп-критериев;
ранжировать критерии выбора по важности – присвоить им веса;
• разработать единую (одинаковую для всех критериев) однонаправленную (то есть высший балл – это хорошо, низший – плохо с точки зрения сформулированных требований) шкалу оценки для критериев выбора (например, можно оценивать факторы требований в процентах);
оценить участников long list в отношении критериев выбора (по открытым данным, с учетом их достоверности, привлекая доступных экспертов, вендоров или внедренцев – представителей компаний, внедряющих решения)40;
• рассчитать комплексные оценки систем и решений-кандидатов (например, сумму произведений важности (весов) критериев на значения критериев);
• составить short list (3–4 финалиста с наивысшими оценками);
• встретиться с поставщиками систем short list;
• принять решение.
Выбор подрядчиков, которые должны помочь с внедрением и как минимум с начальными шагами сопровождения выбранной системы или решения, проводится по той же процедуре. Отличия состоят в том, что здесь необходимо передать кандидатам запрос-ТЗ на проект со своими требованиями к результату и получить от них коммерческие предложения. Ну и перечень критериев выбора, естественно, другой. Например, такой:
компетенции и экспертиза. Экспертиза в предметной области, в работе с продуктом, технические навыки и знания для внедрения выбранной ИС;
опыт. Подтвержденный опыт успешного внедрения ИС в аналогичных по размеру и бизнес-модели организациях, а желательно и в отрасли;
наличие рекомендаций, отзывов и референсов. Дает возможность убедиться, что подрядчик имеет репутацию высококлассного внедренца, исполняющего работу качественно, в срок и в рамках бюджета;
эффективные коммуникации. Подрядчик должен слышать и понимать клиента, чутко реагировать на его потребности и проблемы. Надо проверить это важное качество во время переговоров;
возможности выполнить проект. К этому критерию относятся количество и квалификация сотрудников, финансовая устойчивость и репутация компании, способность при необходимости или возникновении проблем быстро усилить команду и справиться с проектными рисками;
сроки. Надо формулировать ожидаемые сроки реализации и понимать, как и почему подрядчик будет их выдерживать;
бюджет. Надо понимать эту цифру в формате «под ключ». Не забыть само ПО/лицензии, «железо» и инфраструктуру, услуги консультантов внедрения, обучение персонала, ИТ-поддержку, привлечение своих сотрудников (это обычно ключевые люди от бизнеса, кроме тех, кто напрямую обязан участвовать, они тратят около 20 % своего рабочего времени на такие проекты, что выражается в зарплате, налогах и накладных расходах, – это обычно 1–2 бюджета на внедренцев);
результат. Тут придется читать между строк и мелким шрифтом, так как описания того, что входит и что не входит в проект и его бюджет, могут существенно различаться;
поддержка. После внедрения в течение значительного времени может требоваться техническая и методическая поддержка для решения различных проблем;
• безопасность. Подрядчик должен продемонстрировать свою способность принять надежные меры безопасности для защиты конфиденциальных данных.
Когда что-то делается впервые, неизбежно возникают сложности, особенно если проекты масштабные. На что стоит обратить внимание, готовясь к проекту автоматизации (включая, но не ограничиваясь).
Реалистичная оценка и готовность к участию в проекте внутренних ресурсов организации. Проект автоматизации процессов – это по большей части «бизнесовый» проект. Соответственно, его участниками должны выступать не только внедренцы (знатоки системной платформы), но и управленцы, хорошо понимающие процессы организации и уполномоченные на их трансформацию при внедрении ИС. А кураторами должны быть владельцы и кураторы автоматизируемых процессов. Часто эта необходимость отчетливо не осознается и проекты отдаются на откуп специалистам ИТ, в результате чего и терпят неудачу.
Масштаб проекта и другие проекты оргразвития. Грубо говоря, надо честно ответить, потянет ли организация все эти активности одновременно. На практике оценка потребных ресурсов во временной развертке встречается очень редко. А приводит это к постоянным сдвигам сроков, «наездам» на проектные группы и в целом к вялотекущим проектам с печальным концом.
Внедрение ИС – это проект, именно так это и должно быть реализовано. Весьма распространенное явление: проекта как такового нет, предполагается, что с внедренцами должны работать функциональные подразделения в рамках своих обязанностей. Проектная и рабочие группы по процессам не формируются, проектные роли и структуры управления проектом не создаются, ответственность не формализуется, план есть только у внедренцев, да и те при ползущих сроках на вопрос о плане разводят бровями, четких сроков и бюджета нет и т. п. Интересно, что хуже всего с этим ситуация у относительно небольших проектов. Большие бюджеты управляются лучше, видимо, давит денежная масса ☺.
• Устроит ли организацию внедрение «без подготовки», иначе называемое коробочным, заключающееся в применении внедренцем своей референтной модели («коробки») без кастомизации? Это давний подход, часто используемый в небольших проектах. Инсталлируется «коробка» продукта, и предполагается, что «стандартная» установка и пользователи заставят систему функционировать просто за счет внесения данных при стандартных настройках и минимальных доработках. Хорошая аналогия – костюм, скроенный и сшитый по меркам другого человека. Между тем объем настроек, которые делают систему подходящей для организации, приличен: в общем случае это ролевая структура, права доступа и действий в системе, процессные цепочки и составляющие их функции, которые должны выполняться в системе, шаблоны и формы документов в системе, шлюзы с другими системами, справочники и данные и т. д. и т. п.
• Если организация выбирает внедрение на свои процессы, то надо с самого начала наладить сотрудничество своих процессников с подрядчиками-внедренцами. А если своих процессников почему-то нет, то позаботиться о том, чтобы найти квалифицированных консультантов на рынке. Задача процессников в проекте – разработать процессное ТЗ для внедренцев и вместе с внедренцами!
Упражнение
Если это актуально для вашей организации (в планах есть внедрение ИТ-решения), попробуйте сформулировать:
• требования к ИТ-решению;
• стоп-критерии выбора ИТ-решения;
• long list систем и решений для рассмотрения;
• рейтинг и веса критериев выбора ИТ-решения по важности;
• единую однонаправленную шкалу оценки для критериев выбора;
• перечень критериев для выбора подрядчиков.
Совпадают ли ваши результаты с тем, что считает по этому поводу ваша организация? Если нет, то почему?
2.5.3. Процессы в проектах автоматизации
Как я уже упоминал, основным предметным содержанием проектов автоматизации чаще всего являются процессы организации. Подготовка к внедрению ИС состоит в том, что процессы моделируются (описываются) в текущем виде. Затем при прочих равных моделируется процесс «как должно быть» после внедрения, то есть показывается, какие функции проходят в системе, какие – во взаимодействии сотрудника с системой, какие исчезают, какие меняются, какие добавляются как раз в связи с автоматизацией. Такая модель выступает в качестве ТЗ на внедрение. Кроме того, такой подход дает ряд и других преимуществ для организации:
• принятие решений по изменению процессов в связи с внедрением по наглядным моделям;
• зачастую в ходе проекта автоматизации реализуется и light-совершенствование, к чему весьма располагает понимание текущих процессов и накопленных в них ошибок. Конечно, это усложняет проект внедрения, но пройти мимо очевидных проблем – вряд ли разумный шаг. В то же время специальное усложнение проекта (например, попытка одновременно тут же заняться и сертификацией по стандарту ISO или внедрением Lean Production) точно противопоказано;
• возможность разработать План внедрения не только внедренцам, но и самой организации (в части ее ответственности), ничего не пропустив;
• получить прямое задание на разработку/доработку для самописных решений;
• обеспечить и облегчить:
тестирование системы – возможность сформировать все сценарии процесса и пройти по ним, убеждаясь, что система работает так, как задумано;
создание комплекта сопроводительной документации, инструкций пользователям в части процессных действий, как системных (то есть реализуемых в системе), так и несистемных (реализуемых вручную);
тиражирование системы (например, после пилотного филиала во всех прочих), так называемый roll-out;
обучение пользователей, когда они видят и процесс, и свои действия в нем (то есть в реальных ситуациях их работы), а не изучают отдельные функции системы.
В последние 10–15 лет бурно развивается low-code-автоматизация41. На рынке труда – бум спроса на технических специалистов, способных создавать модели процессов в нотациях, позволяющих трансформировать их в исполняемые приложения, например BPMN 2.0. В ближайшем будущем технология «модель = исполняемый процесс» станет доступной для людей бизнеса, облегчит внедрение многих ИС и сведет к минимуму необходимость обращаться за помощью к программистам-разработчикам и внедренцам традиционных ИС. А эта технология напрямую требует процессного моделирования.
Недавняя пандемия подтолкнула бизнес в направлении перевода активностей в онлайн и к роботизации (как программной, так и «физической»). Многие вещи, которые были недоступны в дистанционном формате (по разным причинам, от косности до трудоемкости), становятся доступными. Этот тренд, который и ранее был отчетливо заметен, сейчас ускорился кратно. Здесь можно видеть два эффекта: однозначный плюс и удобство для потребителя и сокращение количества низкоквалифицированного персонала в организациях.
Еще один эффект, который возможен, но необязателен: какие-то предприятия постараются сделать свои процессы и управление активами более гибкими, способными быстро масштабироваться и сворачиваться, переходить между онлайн- и офлайн-форматами. Но так сделают не все. Многие решат, что пандемия – это случай, который не повторится.
В последние годы все более широкое распространение получает термин «цифровизация». На нее настоящая мода. В широком смысле это процесс внедрения цифровых технологий в самые разные сферы деятельности, а в узком – исключение человека из исполняемых процессов (в отличие от автоматизации, которая рассматривается как усовершенствование процессов с хотя и сокращающимся, но все-таки ненулевым участием человека).
На рынке распространено мнение, что цифровизация однозначно хороша и полезна, что рано или поздно она станет всеобщим законом, а потому, если хочешь преуспеть, надо спешить!
Между тем не все так радужно. По данным компании McKinsey, большинство компаний достигают лишь 30 % результата, которого ждут от цифровой трансформации. Как любое непростое дело, цифровизация имеет свои проблемы, риски и минусы. Вот некоторые из них.
• Высокие затраты. А раз так, то речь должна идти об окупаемости инвестиций. Между тем правилом являются переоценка эффекта и недооценка затрат. Это одна из основных причин провала проектов цифровой трансформации. Если решения принимаются на основе неточной или ложной информации, ничто не спасает такие проекты.
• Основные риски программ цифровизации связаны с отсутствием разработанной и утвержденной стратегии. По данным компании Forrester, отсутствие стратегии – проблема 30 % компаний, провалившихся в цифровизации. Например, Procter & Gamble в 2012 году объявила о намерении стать самой цифровой компанией в мире, но с течением времени бюджет цифровой трансформации сократили на 30 %. Ошибкой были слишком широкие цифровые инициативы без конкретных целей, увязанных с бизнес-целями, что грозило бесполезным внедрением и расходом средств.
• Другая причина провала проектов цифровизации – невовлеченность в процесс топ-менеджеров. Часто они просто не понимают пользы трансформации для компании и отдельных ее оргединиц.
• С этим фактором тесно связана еще одна проблема – сопротивление изменениям со стороны сотрудников. Она усугубляется недостаточно эффективными коммуникациями между исполнителями и всеми заинтересованными сторонами. Особенно рискуют компании без устойчивой корпоративной культуры внедрения изменений.
• Безопасность цифровых процессов, да и вообще цифровых технологий остается важной проблемой. Высоки риски мошенничества, хищений, утечки данных, киберпреступлений.
• Серьезный фактор риска – возможные отказы в обслуживании ИТ-систем, ошибки, сбои и т. п.
• Проблема и фактор риска для немалого количества организаций – передача проектов цифровизации на откуп подрядчику. Это порождает зависимость от поставщиков решений и множество проблем в будущем.
• На сегодня имеют место недостаток опыта успешных цифровых трансформаций и дефицит действительно квалифицированных кадров. Проблемы, с которыми сталкиваются организации, включают, в частности, недостаток навыков в области кибербезопасности, архитектуры приложений, интеграции программного обеспечения, анализа и миграции данных, переноса процессов в облако и обеспечения комфортной дистанционной совместной работы. Система образования серьезно отстает от потребностей цифровой экономики.
• Низкая интеграция систем – правило проектов цифровизации сегодня, к сожалению. Это приводит к изоляции данных и дублированию усилий. Например, использование не связанных между собой CRM- и ERP-систем может привести к неполной, противоречивой или некорректной информации о клиентах и заказах.
• Риски реализовать оцифровку (перевод продуктов или процессов в цифровую форму) вместо цифровизации. Оцифровка – лишь начальный шаг, настоящий эффект может принести разумная и профессиональная цифровизация.
2.5.4. План проекта автоматизации
Здесь я приведу в качестве примера типовой План проекта. Надо иметь в виду, что внедрение конкретных систем может отличаться по последовательности и содержанию этапов. Но общая идеология проектов сохраняется.
Прежде всего до начала работ мы формулируем задачу на проект. Она является преломлением наших требований к ИС в возможностях выбранной системы с учетом опыта и компетенций выбранного подрядчика – такой совместный труд.
Сам проект состоит из двух фаз. Фаза 1. «Подготовка к внедрению ИС». Ее основное содержание – изучение текущих процессов и проектирование новых процессов (после автоматизации). Фаза 2. «Внедрение ИС».
Этап 1. Разработка Соглашений по моделированию. В частности, проектная группа организации совместно с внедренцами-подрядчиками должна определить, на каком уровне детализации следует описывать текущие процессы (подпадающие под процессный объем проекта) и какую информацию показывать на моделях для проектирования целевых процессов.
Этап 2. Моделирование и локальная диагностика процессов. Локальная диагностика проводится с прицелом на задачу проекта, а также на реализацию light-совершенствования. Более нагруженное совершенствование процессов требует высокой квалификации и на практике в таких проектах редко бывает успешным, хотя с точки зрения разумности и целесообразности, безусловно, желательно. Надо также учитывать, что изменения, вносимые системой в процессы, могут вступать в конфликт с мерами по совершенствованию текущих (!) процессов, и разрешить такого рода коллизии зачастую непросто. Таким образом, следует трезво оценивать уровень компетенции привлекаемых к проекту ресурсов и не пытаться ставить перед ними задачки-«неберучки» – итоги могут быть плачевными.
Результат – Альбом (и база данных, набор) моделей процесса «как есть» с результатами локальной диагностики.
Этап 3. Проектирование процесса «как должно быть». В совместной работе процессников, внедренцев и менеджмента организации строятся модели целевого процесса. То есть того процесса, к которому мы должны прийти по итогам автоматизации. На этом этапе важную роль играют внедренцы, показывающие, какие шаги процесса и как именно трансформируются в ходе автоматизации, что возможно, а что невозможно реализовать в системе. На процессных моделях строятся будущие процессы организации. Фактически на этом этапе одновременно осуществляется и анализ процессов, и выбор решений, и их визуализация.
Результат – Альбом (и база данных, набор) моделей процесса «как должно быть». Фактически эти модели являются Техническим заданием на внедрение ИС.
Этап 4. Уточнение Плана внедрения ИС носит технический характер и является переходным к Фазе 2. Необходимо учесть результаты предыдущего этапа в плане проекта и предусмотреть меры для их реализации в системе.
Эта часть проекта в значительной степени вариативна и должна учитывать особенности внедряемой системы. Некоторые нюансы и примеры мы рассмотрим в следующем параграфе. Но очень важным в любом случае является следующий аспект: некоторые внедренцы стараются избежать работ Фазы 1 и сразу приступить к Фазе 2. Это приводит к тому, что сотрудники организации-заказчика просто не понимают, что и как будет работать, как система должна изменить их деятельность. Довольно долго пользователи вообще не могут оценить или применить к себе действия внедренца в проекте, их смысл становится более или менее понятным только к концу внедрения, а то и после него. Тестирование системы тоже проводится в отрыве от реальных процессов, хотя и использует кейсы из жизни. В итоге и качество внедрения получается низким, и организация остается разочарованной, вынужденной заниматься доводкой проекта после ухода внедренца.
Этап 5. Подготовка функциональной модели ИС. Разрабатывается и демонстрируется заказчику контрольный пример, показывающий, как именно будет работать система (движение документов и данных, аналитические возможности, справочные и отчетные функции и прочее в зависимости от назначения системы). Для контрольного примера выбирается распространенный, простой (не самый замороченный как минимум) кейс работы системы (и, соответственно, сценарий процессов). Типовой функционал ИС максимально (но, возможно, не полностью, если по итогам проектирования процессов «как должно быть» выявлена необходимость масштабного перепрограммирования) дорабатывается на основании результатов этапа 4, чтобы соответствовать согласованным процессам. Считается, что в функциональной модели не менее 80–90 % операций должны соответствовать необходимому функционалу и согласованным процессам «как должно быть». Составляется список необходимых доработок, в том числе тех, которые при проектировании процессов могли быть не видны или неочевидны. Этот этап играет важную роль в проекте, поэтому необходимо, чтобы сотрудники организации могли оценить контрольный пример, будучи максимально подготовленными. Поэтому весьма полезно провести базовое обучение работе с системой до старта этапа. Обучение должны пройти процессники, будущие пользователи и ИТ-специалисты компании.
Этап 6. Настройка ИС в соответствии с функциональной моделью и ТЗ на внедрение. На этом этапе, в частности, типовой функционал дорабатывается в соответствии с потребностями организации. Настроенная система проходит тестирование (которое иногда переносится на конец этапа 7). Для этого готовятся сценарии тестирования (как указано ранее, модели целевых процессов весьма облегчают эту работу и делают ее системной).
Этап 7. Подготовка к запуску ИС в эксплуатацию. На этом этапе выполняются, например:
подготовка инструкций и обучение пользователей работе с системой на основе контрольного примера функциональной модели. Сотрудники должны «ручками» прогнать контрольный пример как минимум;
подготовка правил запуска ИС (в том числе наполнения ее данными и интеграции с другими системами организации);
перенос начальных данных в соответствии с правилами запуска ИС;
интеграция с существующими системами и запуск обмена данными с ними;
• настройка прав и ролей пользователей.
Этап 8. Опытная эксплуатация системы, возможно, параллельно со старой системой-аналогом. Отслеживаются и исправляются все ошибки и нежелательные отклонения в работе системы по сравнению с ТЗ. Пользователи системы должны получить и закрепить навыки работы с ней. Кроме того, дорабатываются инструкции для работы со сложными кейсами и редкими сценариями, а также проводится дополнительное обучение, если это необходимо. В то же время сама система проходит проверку работой с реальными данными. Внедренцы постоянно оказывают помощь пользователям компании.
По окончании проекта система запускается в промышленную эксплуатацию уже силами сотрудников организации. Внедренцы какое-то время сопровождают работу системы, консультируя «по вызову».
Упражнение
Участвовали ли вы в проектах автоматизации деятельности? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?
2.5.5. Особенности проектов автоматизации
Как было упомянуто ранее, планы проектов внедрения различных типов информационных систем могут иметь свои особенности.
В предыдущем параграфе приведен типовой план, в первую очередь ориентированный на системы классаERP. В то же время вендоры различных систем этого класса продвигают свою методологию внедрения. Кроме того, сами внедренцы могут вырабатывать свои подходы. Как же быть в этой ситуации заказчику? Имея под рукой приведенный план, проверять на логичность и полноту то, что предлагает подрядчик. Но самое главное – настаивать на процессно-ориентированном внедрении! А именно, на двух фазах проекта. В результате первой фазы должно быть сформировано процессное ТЗ на внедрение, которое показывает самой организации, как именно она будет работать после автоматизации. И эта модель должна быть предметом консенсуса компании и внедренца.
Эти системы изначально ориентированы на автоматизацию процессов. Собственно, их настройка и состоит в моделировании и запуске процессов «как должно быть». Массовым стандартом таких проектов является нотация BPMN 2.0.
Особенность таких проектов состоит в том, что система предполагает развиваться в части расширения процессного объема прямо в ходе промышленной эксплуатации. То есть проект состоит из пилота, инсталляции системы и запуска в промышленную эксплуатацию.
Основное содержание пилотного проекта составляют этапы 1–3, описанные в предыдущем параграфе. В ходе модифицированного (по сравнению с типовым) этапа 3 решаются вопросы, связанные с проектированием исполняемой модели процесса (поэтому и используется нотация BPMN 2.0). В частности, создаются модели (схемы) данных и прототип системы, а по окончании проектирования выполняются работы с данными и правами доступа, интеграция системы с другими сервисами (если это необходимо для запуска и реализации процесса), проводится тестирование автоматизированного процесса, разрабатываются (при необходимости) инструкции пользователя. Можно сказать, что работы этапов 4–7 типового плана переносятся на этап 3, поскольку не являются особенно масштабными. Этап 3 можно назвать «Проектирование и автоматизация пилотного процесса». После этого реализуется этап 8 «Опытная эксплуатация системы».
Если заказчик удовлетворен возможностями системы, продемонстрированными в ходе пилотного проекта, и принял решение о ее внедрении в промышленную эксплуатацию, то он приобретает нужный пакет лицензий, инсталлирует их и выполняет необходимые настройки (например, отчетности по процессам для целей их анализа и пр.).
После этого начинается промышленная эксплуатация системы силами сотрудников организации. Они реализуют работы пилотного проекта (за исключением этапа 1, так как Соглашение о моделировании обычно годится и для дальнейших работ) в отношении других процессов, подлежащих автоматизации.
Системы класса RPA42
Процессы, подходящие для автоматизации средствами RPA, должны допускать исключение человека. То есть это хорошо алгоритмизируемые, обычно довольно высокочастотные процедуры, не требующие креатива и нестандартных ответственных решений, отнимающие много ресурсов сотрудников.
Сами системы этого класса, как и системы BPMS, ориентированы на работу именно с процессами. Их следует воспринимать как платформы, расширяющие свою зону покрытия во время эксплуатации. То есть проект внедрения обычно ориентирован на пилотный процесс, инсталляцию системы и запуск ее в промышленную эксплуатацию.
На что следует обратить особое внимание.
Радикальное перепроектирование текущего процесса43. Роботизированный процесс – совсем другой по сравнению с «человеческим». Фактически требуется реинжиниринг. Спасает от серьезных сложностей только то, что обычно внедрение идет на небольших процедурах.
Сложность интеграции. Внедрение RPA часто требует особых и значительных усилий для интеграции с существующими системами и процессами.
Обучение и адаптация. Хотя сотрудники и вытесняются из автоматизируемых процессов, их требуется обучать как работе с новыми технологиями (боты и средства искусственного интеллекта), так и изменениям в смежных процессах, вызванным внедрением роботизированных процедур.
Поддержка и обслуживание. Системы RPA требуют регулярного обслуживания и обновления программного обеспечения для стабильной работы. Следует осуществлять мониторинг функционирования роботов и решать возникающие проблемы.
• Безопасность данных. Роботизация процессов может повысить риски утечки данных. Следует предусматривать настройку систем и/или процедур безопасности, мониторинг доступа к данным, обучение сотрудников вопросам безопасности и т. п.
План проекта внедрения системы RPA представляет собой облегченный вариант типового плана проекта автоматизации (см. параграф 2.5.3). Подход к его составлению похож на тот, что используется для BPMS-систем: внедрение через пилотный проект. Пилотный процесс выбирается до старта проекта. Начало проекта (фаза 1) стандартное, этапы фазы 2 реализуются в более сжатом виде.
Этап 1. Разработка Соглашений по моделированию. Требования к описанию текущего процесса в значительной степени облегчены, так как целевой процесс фактически будет перепроектированием в другой логике.
Этап 2. Моделирование пилотного процесса. Локальная диагностика не имеет особого смысла, хотя иногда ее проводят, чтобы убедиться в том, что текущие «болячки» процесса будут ликвидированы при автоматизации.
Этап 3. Проектирование RPA-процесса44.
Этап 4. Разработка и тестирование программных роботов пилотного процесса. Выполняются настройки, интеграция с имеющимися системами, пишутся соответствующие скрипты и сразу же выполняется тестирование, чтобы обеспечить корректную работу (по предварительно разработанным сценариям тестирования). Сотрудники компании-заказчика проходят необходимое обучение.
Этап 5. Опытная эксплуатация программных роботов пилотного процесса. Выполняется мониторинг работы ботов, решаются возникающие проблемы.
Промышленная эксплуатация системы RPA предусматривает ее развитие (автоматизацию новых процедур), регулярный мониторинг эффективности и работоспособности уже внедренных роботов, обновление ПО, выявление и устранение проблем, обучение новых пользователей и сотрудников.
Особняком стоят проекты так называемых «самописных» решений, когда организация обладает (или думает, что обладает) достаточными компетенциями для самостоятельной разработки нужной системы и при этом пребывает в убеждении, что это решение будет лучше всего того, что предлагает рынок, причем настолько, чтобы оправдать необходимые инвестиции ресурсов и времени, а также имеющиеся риски. Такие проекты довольно сложны и почти всегда уникальны, поэтому здесь мы их рассматривать не будем.
Упражнение
Участвовали ли вы в проектах внедрения систем ERP, BPMS, RPA? С какими особенностями сталкивались? Какой план проекта использовался? Отличается ли он от описанного? Чем вызваны расхождения, если они есть?