Понятное дело, ботаны из IT-департамента «делают историю» корпоративной информатизации. Это они, пройдя вверх по карьерной лестнице, становятся мудрыми гуру – CDO (Chief Digital Officer), чьи знания и опыт о превращении данных в актив предприятия в виде емких тезисов компании благоговейно высекают на корпоративных каменных скрижалях.
Это шутка. Но в каждой шутке, как говорится, есть только доля шутки. Действительно, опытные IT-директора крупных компаний – это уникальные специалисты. Конечно, их авторитет и компетенции оказывают влияние на тот путь цифровизации, точнее, цифровой трансформации, по которому продвигаются конкретные предприятия. Однако пришла пора несколько скорректировать наши представления о движущих силах корпоративной информатизации. Самое интересное в этой истории – то, как меняется роль конкретной личности.
Что изменилось?
Изменился уровень корпоративной цифровизации. Идея всепроникающей цифровизации обрела плоть и кровь в виде реальных мероприятий цифровой трансформации со всеми соответствующими атрибутами: задачи, IT-проекты, ресурсы, KPIs, трансформации бизнес-процессов. Процессов, проектов и требуемых ресурсов много, к тому же, они тесно интегрируются друг с другом. В результате сложилась парадоксальная ситуация: IT-департамент, который отвечает за корпоративную информатизацию, оказывается «бутылочным горлышком», тормозящим эти процессы. Все претензии к «водопадному» методу IT-внедрений, которые сегодня высказываются (и, надо сказать, они справедливы), родом оттуда – из ограниченности сил и средств, участвующих в реальных проектах.
На этом фоне понятно, что концепция Low-code, во-первых, не могла не появиться на свет, во-вторых, не могла не стать магистральным направлением реализации корпоративной информатизации. Просто потому, что по-другому никак. По мере того, как IT все больше сливаются с бизнес-процессами, IT-персонал все глубже погружается в специфику бизнес-процессов, а бизнес-подразделения становятся не отстраненными заказчиками IT-систем, а непосредственными участниками проектов внедрений. И это вовсе не конец истории, а, наоборот, только начало нового захватывающего этапа.
Что за новый этап?
По поводу Low-code все еще ломаются копья специалистов. Однако, по факту, споры уже идут не по поводу самой идеи Low-code, ведь программные инструменты все больше превращаются в «конструкторы», ориентированные на применение непрофессионалами в IT. Споры вокруг Low-code перешли в сферу практического использования.
Все разработчики Low-code систем, в первую очередь, систем управления бизнес-процессами (BPMS), заняты тем, что реализуют в своих продуктах те или иные методы организации работы «гражданских», которые ограничивают возможности их «творчества» в тот момент, когда возникает риск нарушения работоспособности IT-систем. Таких методов известно немало. Например, в Comindware Business Application Platform единая среда разработки и выполнения бизнес-приложений, в которой работают как «гражданские», так и IT-профессионалы, обеспечивается на достаточно глубоком уровне, в первую очередь, с помощью онтологических моделей «под капотом», которые обеспечивают возможность создания решений для работы с данными, формами и документами без традиционного программирования.
Нетривиальный вопрос: как обеспечить гармоничное единство действий «гражданских» и профессиональных разработчиков? Ведь во многих организациях «баланс интересов» внутренних бизнес-заказчиков и IT-департамента в ходе цифровизации еще не достигнут. Это отсутствие синергии подчас заменяется «принуждением к совместному достижению результата», которое реализуется через административное давление, избегание ответственности и подковерную борьбу. Но это жизнь – так проявляются особенности корпоративной культуры, сложившейся в компании на момент перехода к активной фазе цифровой трансформации. И здесь возникает вопрос о роли и месте «гражданских» разработчиков в сложившейся иерархии должностей.
Кто ты, «гражданский» разработчик?
В условиях цифровой трансформации кардинально меняются привычные представления о том, какие сотрудники занимаются разработкой цифровых процессов и цифровых продуктов. Концепция Low-code услужливо подбрасывают сентенцию: разработчиками становятся все. Образно говоря, сам себе разработчик? Не совсем. Скорее, сам себе менеджер. Точнее, менеджер, отвечающий за процесс.
Тогда Low-code платформа BPMS – это не просто инструмент визуального рисования схем, хотя это качество, несомненно, присутствует. И Low-code BPMS-платформа – это больше, чем управление процессами. Это инструмент реализации функций менеджера, платформа для обеспечения цифровой деятельности менеджера. А в чем, собственно, выражается это свойство?
Обычно говорят, что главные дивиденды от использования Low-code платформы лежат в радикальном увеличении объемов работ, которые теперь под силу одному человеку. При этом важно отметить, что дело не только в автоматизации рутинных процессов. Low-code платформа становится умным партнером менеджера, причем, в основной, а не вспомогательной деятельности. Покажу далее на примерах, как кардинально меняется содержание работы менеджера, когда он становится «гражданским разработчиком».
Одним махом семерых… нет, десятерых… убивахом? Нет, заменяхом!
В авиакомпании S7 Airlines есть особое подразделение – авиационный учебный центр S7 Training. Он осуществляет обучение летно-технического персонала по 80 направлениям подготовки, а его услугами пользуются сотрудники S7, а также других авиакомпаний.
Бизнес учебных центров с организационной точки зрения достаточно сложен. В учебном процессе задействовано дорогостоящее оборудование, которое не должно простаивать или оказаться неисправным. Еще одна забота – круглосуточное обслуживание слушателей, ведь они прилетают сюда в командировку, их нужно поить, кормить предлагать идеи для проведения свободного времени. В фокусе внимания Александра Черняева, руководителя системы менеджмента качества в учебном центре, огромное количество разноплановых бизнес-объектов и связанных с ними процессов: авиа-тренажеры, учебные аудитории, гостиницы, кафе, спорткомплекс, не считая объектов коммунального хозяйства.
Очевидно, что рост бизнеса учебного центра привел к усложнению взаимосвязанных процессов, а рост неувязок в планировании последовательных мероприятий – это удар по репутации и финансовые потери. Главной проблемой были сроки изменений в процессах. Для внесения любого изменения в календарное расписание требовалось изменить данные в трех IT-системах, в чем принимало участие 12 человек. Они согласовывали изменение, используя MS Outlook, таблицы Excel и телефон, примерно два дня.
Вроде бы, чисто менеджерская задача управления процессами. Но в старом варианте сотрудники были перегружены, а тренажерные ресурсы – недозагружены. В рамках старой IT-парадигмы проблема фактически неразрешима: даже если предоставить сотрудникам инструменты онлайн-коммуникаций, радикально повысить эффективность взаимодействия сотрудников не удастся, поскольку причина неэффективности – в самих процессах, а не в средствах их автоматизации.
Все изменилось после внедрения Low-code BPMS-платформы, которую решили использовать для повышения эффективности и гибкости всех процессов обслуживания клиентов: от бронирования временного слота на тренажере до логистики сопутствующих процессов. И теперь Александр Черняев в одном лице «дирижирует» всем расписанием (да-да, он заменил 12 сотрудников!), а на изменения в расписании уходит два часа вместо прежних двух суток.
Сам процессный слой системы BPM автоматически отрабатывает все этапы внесения изменений, информирует клиентов и сотрудников о ключевых статусах процессов через мессенджеры, поддерживает актуальное и достоверное состояние баз данных. В результате накладки в расписаниях ушли в прошлое (минус репутационные риски), в оборот удалось вернуть около 10-15% тренажерной емкости (плюс дополнительная доходность) и освободить от рутинных операций более десятка сотрудников (плюс экономия на оптимизации персонала).
И вот чем еще хороша методология Low-code: она ориентирована на специалистов, не являющихся профессионалами в IT. А это значит, что любой менеджер, заинтересованный в улучшении вверенных ему процессов, может достичь нужного результата самостоятельно. Достаточно только дать ему соответствующий инструмент.
Как, например, в административно-хозяйственном отделе «Сургутнетегаза». Известно ведь, что заявки АХО практически никогда не оказываются в списке приоритетных задач IT-отделов, поскольку они не относятся к разряду business critical. Но Алексей Денискин, сотрудник «Сургутнефтегаза», решил не мириться с этим состоянием. И в тот момент, когда сотрудникам бизнес-подразделений компании «Сургутнетегаз» стала доступна Low-code платформа BPMS, он самостоятельно изучил инструмент и создал автоматизированную систему обработки заявок по поддержанию административно-хозяйственных нужд организации. Создал систему самостоятельно, обладая лишь знаниями о своей сфере деятельности и желанием ее улучшить. В результате заметно сократилось время выполнения заявок и улучшилось качество технического обслуживания и ремонтных работ в части как инженерных систем, так и инфраструктуры объектов недвижимости. В масштабе компании это дало оптимизацию расходов и повышение качества управления объектами в части эксплуатации, а также сокращение непроизводительных расходов за счет автоматизации процедур взаимодействия между сотрудниками.
Что вы теперь скажете о роли личности в истории корпоративной информатизации? На капитанском мостике – по-прежнему IT-директор, но ключевые бизнес-процессы в подразделениях выводят на принципиально новый уровень реализации отвечающие за них менеджеры. Это они настоящие герои происходящей сегодня Low-code революции.
Также читайте:
Изменилось то, что раньше технологически изменения и изменения в бизнес-процессах можно было планировать на длительный период, а сейчас планы меняются быстрее чем исполняются.
В этом смысле под трансформацией стоит понимать такую организацию деяельности, которая будет позволять достигать догосрочных целей компании. И слово цифровое тут далеко не главное, и отчасти случайное.
Хорошие истории.
Действительно, почему бы человеку, хорошо разбирающемуся в ситуации, понимающему причины появления вокруг него многочисленных проблем и имеющему соответствующие инструменты формализации, не взять на себя часть ответственности за происходящее и не попытаться эти проблемы решить?
Вопрос лишь в том, а если он ошибается или предложит неверное решение? Насколько он профессионально подготовлен для такой работы?
Кто должен и может ему помочь?
Внедряют корпоративную культуру согласно процедурам корпоративной политики компании, которая отвечает за цифровизацию. А вы как думали? Вжух - и готово? Нет, это труд - и прежде всего гуманитарный. Это я вам авторитетно, как технарь 25+ лет стажа заявляю.
Все, круг замкнулся. Ответ получен и подтвержден.
Как можно внедрить корпоративную культуру согласно процедурам?
Заинтриговали!
Модели чего? Есть такие модели на все случаи жизни, любых компаний и задач?
Или сначала ее/их нужно разработать и верифицировать?
Мы говорим о статье и поднимаемых в ней вопросах - или о Вашем профессиональном опыте? Не все так талантливы и подготовлены для выполнения новых задач. Но даже на Вашем примере видно, что ошибка очень возможна, если не неизбежна.
Почему Вы не воспользовались Вашим же советом из п.1?
Нельзя ли как-то переформулировать этот пункт? При чем здесь корпоративная культура, корпоративная политика и замкнутый круг?
Напомню, что статья о корпоративной цифровизации и тех, кто в ней так или иначе участвует.
1. Лучше расскажите, как можно внедрить корпоративную культуру без корпоративной политики?
2. Модели того, ЧТО мы хотим трансформировать в цифру для достижения ЧЕГО-ТО.
3. Was mich nicht umbringt, macht mich stärke
4. О том, что мало кто может дать ответ на простейший вопрос: ЧТО мы хотим получить в итоге трансформации в виде KPI.
Я что-то об этом или подобном говорил? Для начала я даже не понимаю, что значит "внедрить корпоративную культуру".
Простите, не понял. Это ответы на мои вопросы?
Вопрос к менеджменту компании. Обычно цели внедрения любой системы в явном виде указаны в проектных документах.
С этого и надо было начинать. Есть разные примеры, например корпоративная культура деловой переписки.
У меня на персональном ящике постоянно приходят какие-то документы, запросы на совещания, внутренние приказы итд от разных организаций, которые меня приглашали для разных консультаций, но потом передумали по каким-то причинам.
Вот что происходило: мой личный адрес попал в какие-то группы, контакты итд, после чего его включают в корпоративные списки рассылки и шлют разное всякое. Самый запоминающийся документ - в качество повода для сокращения неугодных сотрудников, поднять их связи с недружелюбными связями. Самое запоминающееся совещание - где обсуждали мою кандидатуру. С корпоративного аккаунта я вышел по их просьбе, но личный-то остался. Было очень приятно послушать о себе правду.
А вот если корпоративная культура привита, то:
Да, конечно. Но обычно они называются иначе - например, e-mail etiquette, если мы о переписке. Много вариантов, можно адаптировать под себя.
Для меня это относится к документообороту и внутренним регламентам. Правила обычно довольно жесткие.
Корпоративная культура как термин обычно употребляется в другом контексте, в связи с чем и возникло непонимание по поводу ее внедрения.
Прелесть Low-code подхода, в том, что цена исправления "ошибки" минимальна.
Не нужно посыпать голову пеплом перед IT, оправдываться за "слитый" не туда бюджет перед руководством, уходить на новый цикл ТЗ-реализация-тестирование-прод..
Нужно просто поправить БП/форму. Причем, вы можете сильно удивиться сравнив первую версию с тем, что увидите через 1-2 года активной реальной работы и практической оптимизации.
"Кто должен и может ему помочь"- вовлеченные в процесс сотрудники, внешние BPM-консультанты.. кто угдоно. Эксперименты, лучшие практики и т.д. - все становится сильно реальнее, т.к. цикл внедрения сокращается до дней-недель.
Есть данные о категориях таких ошибок ( ... на уровне бизнес-процессов ...) и стоимости их исправления? Поделитесь?
Если мы говорим о паре лет активной работы в области практической (!) оптимизации бизнес-процессов и использовании соответствующих инструментов, как это связано с примерами в статье? Там идет речь, насколько я понял, о том, что героем становится любой.
Кто угодно - это не совсем тот ответ, на который я рассчитывал.