Цифровая трансформация государственного управления – одна из наиважнейших задач для современной России, и наряду с этим – это длительный процесс, который требует вовлечённости всех органов власти на всех уровнях. В этом процессе серьёзная нагрузка ложится на субъекты Российской Федерации, которые, используя методики, стандарты и инструменты, разработанные федеральным центром, самостоятельно осуществляют трансформацию региона, активнейшим образом содействуют расположенным на своей территории муниципалитетам, у которых зачастую нет собственных цифровых подразделений и департаментов и в целом ресурсов для осуществления трансформации.
Руководитель проектного офиса Центра цифровой трансформации Республики Татарстан Виктор Щепинов рассказывает о трендах в проектировании цифровых организаций и делится своим опытом.
Для того чтобы эффективно выполнить возложенные задачи областям, краям, автономным округам и республикам необходимо тщательно отнестись к организации подразделений, отвечающих за координацию цифровой трансформации, обеспечить соответствие организационной и проектной структуры возложенным функциям.
При проектировании организации необходимо учитывать три перспективы:
системную (функциональную)
операционную
культурную.
Системный взгляд раскрывает функциональные требования к организации – это то, чего мы хотим достичь, необходимые характеристики системы, значимые ценности для заинтересованных сторон, дизайн-параметры, раскрывающие, как мы структурно собираемся удовлетворить функциональные требования, какие будут подразделения, их роли. Операционный подход даёт видение того, как мы выстраиваем взаимодействие между подразделениями при выполнении конкретных задач. Культурный подход определяет ценности и паттерны поведения, которые должны способствовать достижению целей и соответствовать разработанной модели.
В целом мы ожидаем от регионального офиса цифровой трансформации выполнение следующих функций:
создание, внедрение, развитие и эксплуатация цифровых решений;
оптимизация и реинжиниринг процессов государственного управления и оказания государственных услуг;
государственный заказ и выполнение мероприятий государственных программ;
координацию и методическое сопровождение органов государственной власти.
Как вариант, можно напрямую переложить эти функциональные требования на дизайн-параметры, и иногда это действительно работает, но нужно учитывать, что каждое подразделение (департамент, управление, отдел, сектор) должно выполнять свою функцию, не оказывая негативного влияния на способность других подразделений выполнять функции и достигать своих целей.
В данном примере мы неизбежно получим множество зависимостей, так как для разработки цифровых решений необходимо взаимодействие с органами власти, для проведения реинжиниринга – глубокое понимание возможностей цифровизации, для осуществления государственных закупок – требования к тому, что именно требуется закупить, а всем остальным департаментам самим нужно осуществлять государственные закупки.
Большое количество зависимостей между подразделениями приводит к целому ряду проблем. Конфликты, размытие ответственности, избыточная координация, снижение производительности – это ещё не полный перечень негативных эффектов, которые можно получить. Наряду с этим разумный уровень зависимостей для государственного проектного офиса жизненно важен, так как необходимо соблюдать нормы в сфере закупок, стандартизировать документацию, строго контролировать информационную безопасность, соответствовать прочим методикам и постановлениям. Для того чтобы решить от каких зависимостей следует избавиться в первую очередь, а какие можно и оставить, необходимо определить их вид.
Зависимости бывают трех видов
общая (pooled) – существует служба, обладающая определённым объёмом ресурсов. Например, служба подбора персонала, и все прочие стороны взаимодействия обращаются в данную службу стандартизированным способом. Тут необходимо рассчитать, чтобы объёма ресурсов службы хватало для отработки прогнозируемого количества обращений;
последовательная (sequential) – подразделения выполняют действия в строгой последовательности друг за другом. Например, при создании инфраструктурных объектов сначала одно подразделение выполняет проектно-изыскательные работы, потом другое – строительно-монтажные, возврат на предыдущие этапы не предусматривается;
взаимная (reciprocal) – осуществляется постоянный обмен результатами. Например, при разработке программного обеспечения, когда подразделения анализа, разработки и тестирования циклично возвращают друг другу одну и ту же задачу до окончательного исполнения (именно для устранения этого типа зависимости в своё время придумали Scrum).
Согласно исследованиям, наибольший коэффициент координационных издержек свойственен взаимным зависимостям и именно их и следует в первую очередь устранять. Один из вариантов – включить все операции, требующие взаимной зависимости, внутрь одного подразделения, команды. Существуют и другие способы устранения зависимостей, но их рассмотрение является предметом отдельных исследований и выходит за рамки данной статьи.
Предлагаю перейти к раскрытию модели проектного офиса, успешно апробированной в Центре цифровой трансформации Республики Татарстан, где, по моему мнению, найден адекватный баланс между централизацией и устранением излишних зависимостей.
Мы распределили производственные задачи между полунезависимыми продуктовыми направлениями (трайбами, портфелями), объединёнными вокруг одного лидера (руководителя портфеля проектов). Основными свойствами этих направлений являются скорость выполнения задач и адаптивность при изменении внешних условий.
В нашем случае эти портфели сформированы по принципу разделения предметных областей следующим образом:
городская инфраструктура и жилищно-коммунальное хозяйство;
культура, образование и молодёжная политика;
промышленность, сельское хозяйство и предприятия малого и среднего бизнеса;
социальная защита населения;
строительство и пространственные данные;
финансы и делопроизводство.
Принцип разделения и количество портфелей могут быть и другими. Например, портфели можно сформировать по группам заинтересованных лиц, при этом следует учитывать конкретные региональные особенности и руководствоваться оперативной обстановкой. В конце концов, состав портфелей не константа и, скорее всего, будет изменяться с течением времени.
Вышеуказанные портфели поддерживаются общими сервисами, функционирующими согласно концепции Enterprise Service Management – стандартизированные точки входа, предсказуемый срок исполнения обращений, измерение и контроль ключевых показателей эффективности. Основными свойствами общих сервисов являются контроль соблюдения стандартов и обеспечение высокой надёжности выполнения функций.
Для регионального офиса цифровой трансформации общие сервисы можно разделить на следующие группы:
государственные закупки и заказ;
делопроизводство;
информационная безопасность и инфраструктура;
кадры, управление персоналом;
экономисты, бухгалтерия;
юристы, правовое обеспечение.
Необходимо обеспечить ревизию процессов таким образом, чтобы зависимости между продуктовыми портфелями и сервисными подразделениями приводили к наименьшим координационным издержкам.
Внутри проектного офиса мы применяем матричную организационную структуру управления. Это поддерживает высокий технический уровень основной деятельности и стимулирует профессиональное развитие сотрудников.
В зависимости от потребности в каждый портфель гибко распределяется требуемое количество FTE нужного типа, в какой-то сфере может быть больше организационных задач, в какой-то – аналитических, от портфеля к портфелю может разниться соотношение цифровых решений, находящихся в данный момент в разработке и эксплуатации.
Приведу описание каждой из ролей
Руководитель портфеля проектов (Product Owner, Лидер трайба) – представитель «бизнеса» для команды. Это внутренний заказчик, обеспечивающий взаимодействие с органами власти и жителями. Он приоритезирует мероприятия и отвечает за то, чтобы работа приносила максимальную ценность заинтересованным лицам.
Руководитель проекта (Scrum Master) – драйвер исполнения задач, который обеспечивает соблюдение методики управления проектами, исполнение бизнес-процессов, поставку релизов. Управляет работой команды, отвечает за результат.
Аналитик (бизнес-аналитик) – основной исследователь. Он изучает и проводит реинжиниринг процессов, вносит предложения по оптимизации работы, разрабатывает требования.
Администратор проекта (менеджер по информационным технологиям) – «рабочая лошадка», на которой всё держится. Он обеспечивает эксплуатацию и техническую поддержку разработанных цифровых решений, управляет государственными закупками.
Технический лидер (ресурсный менеджер) – начальник ресурсного подразделения, который назначает сотрудников на проекты, управляет нагрузкой, следит за развитием, помогает в решении сложных задач, отвечает за мотивацию. Важно, чтобы он был непосредственным линейным руководителем своих специалистов.
Поток поставки ценности в такой модели усреднённо выглядит следующим образом:
заинтересованные лица напрямую или через опосредованные инструменты приносят свои потребности и боли, которые помещаются в бэклог;
руководитель портфеля проектов приоритезирует элементы бэклога, согласно своему пониманию отрасли, политической ситуации и прочих факторов;
аналитики в постоянном канбанообразном процессе берут наиболее приоритетные элементы из бэклога и подготавливают их, описывая требуемое состояние после цифровизации;
руководитель проекта управляет технической командой, распределяя готовые элементы бэклога между итерациями (спринтами) длиной от одной до четырёх недель.
Техническая команда, как правило, находится на стороне подрядчика – коммерческой компании IT-аутсорсера, но в нашей практике есть также случаи, когда разработчики привлекаются напрямую в штат. К такому методу можно прибегнуть, если на проекте нужна максимальная гибкость (которую на данный момент нельзя получить, привлекая подрядчиков в рамках 44-го федерального закона о закупках).
Последней по порядку, но не по значению, необходимо рассмотреть культурную перспективу, без которой системные и операционные усилия не принесут желаемого результата.
Кроме того, что руководитель цифровой трансформации региона должен безусловно поддерживать стремление к гибкости, крайне важно, чтобы директор регионального офиса цифровизации, равно как и его сотрудники, придерживались определённого культурного кода.
Я определил 7 принципов, которые рекомендую использовать для корпоративной культуры гибких организаций цифровой трансформации.
Принцип №1 «Итеративность». Главный приоритет и мерило результата цифровизации – быстрая и постоянная поставка ценных функций и возможностей заинтересованным лицам, будь то обычные граждане, пользователи в органах власти или лица, принимающие решения. Поставки необходимо производить итеративно и инкрементно, с наименьшим разумно возможным шагом.
Принцип №2 «Адаптивность». Требования к осуществлению трансформации не статичны, они должны постоянно развиваться в тесном взаимодействии с заинтересованными лицами, жителями, адаптироваться к изменениям в стране и вновь возникающим потребностям граждан. Новые вызовы необходимо принимать в работу на всех этапах трансформации.
Обязательно вовлекайте всех участников – граждан, технических специалистов, чиновников и работников бюджетных организаций в генерацию идей и предложений для развития. Даже самые безумные, на первый взгляд, идеи могут очень хорошо «выстрелить» в какой-то момент. Это не значит, что надо бросаться, сломя голову, реализовывать любой каприз, это значит, что любой каприз необходимо учесть, изучить, записать в бэклог и присвоить приоритет.
Принцип №3 «Мотивация». В команду офиса цифровой трансформации надо подбирать мотивированных специалистов, искренне любящих своё дело, создавать им наилучшие возможные условия для труда, доверять им сделать свою работу, приветствовать творческий подход к варианту реализации.
В текущих условиях подавляющее большинство государственных организаций не может конкурировать с коммерческими IT-компаниями по уровню заработной платы и забирать лучших профессионалов, поэтому ставку необходимо делать на людей с горящими глазами, на молодёжь, жаждущую развития.
Принцип №4 «Открытость». Необходимо приветствовать и развивать все виды коммуникаций в командах, постоянно развивать самоорганизацию и автономность. При этом важно следить, чтобы количество членов одной команды не превышало 9 человек, иначе трудозатраты на коммуникацию становятся неэффективными. В таких случаях помогут методики масштабирования, такие как SAFe, LeSS, Nexus.
Регулярно открыто рефлексируйте и улучшайте процессы, при этом не уходя в постоянное самокопание и неуместную критику.
Принцип №5 «Доступность». Необходимо поддерживать высокий темп работы, все члены команды цифровизации должны двигаться к максимально высокой доступности. В идеале все должны находиться всё рабочее время лично в одном помещении, здании. Длительные паузы в работе и задержки в коммуникации могут оказаться крайне вредными и даже губительными для достижения намеченных целей.
При этом не менее важно, чтобы сотрудники имели достаточно свободного времени, чтобы качественно восстанавливать силы. Регулярные переработки или выдёргивание из личного времени со срочными поручениями неминуемо приведут к выгоранию и потере эффективности.
Принцип №6 «Простота». Лишней и ненужной работы необходимо избегать всеми силами, постоянно поддерживать стремление решить каждую задачу максимально простым способом, но при этом соблюдать стандарты качества. Не изобретайте «велосипеды», но и не используйте «костыли».
Зачастую заинтересованные лица приходят с решением, а не проблемой – не ленитесь докопаться до болевой точки, ведь только так возможен реинжиниринг и упрощение самой сути процесса, а, следовательно, и подлинная трансформация.
Принцип №7 «Техничность». Наилучшие технические практики и инструменты обязательны к изучению и внедрению. Системы управления проектами и контроля версий, сервис-деск и база знаний, CI/CD, автотесты и мониторинг событий, статические и динамические анализаторы кода – это только базовый минимум, который позволяет добиться приемлемого уровня качества осуществления цифровой трансформации.
Перенимайте опыт коммерческих IT-компаний и других регионов, посещайте тематические конференции – это потребует немного бюджета, и он окупится сторицей.
В завершение статьи отвечу на вопрос в заголовке – да! Гибкость возможна при децентрализованном структурном дизайне, который поддерживается общими сервисами и корпоративной культурой.
Список использованной литературы:
Harry Mikel; Mann Prem; De Hodgins Ofelia; Hulbert Richard; Lacke Christopher, Practitioner's Guide to Statistics and Lean Six Sigma for Process Improvements, John Wiley and Sons, 2011, ISBN 9781118210215
Worren Nicolay, Organization Design Simplifying Complex Systems, Second Edition, Routledge, 2018, ISBN 9781315145112
Pavlichenko Ilia; Ramos Cesario, Creating Agile Organizations: A Systemic Approach, First Edition, Addison-Wesley Professional, 2022, ISBN 9780135853191.
