Полезные материалы
Этапы Agile-трансформации финансовой функции компании
Статья описывает этапы Agile-трансформации финансовой функции компании
Agile-трансформация. Насколько знакомо это выражение для специалистов в сфере IT, банковской сфере и в сфере стартапов, настолько же незнакомым оно является для экспертов финансового блока. Иногда даже для тех финансовых экспертов, которые работают в вышеуказанных компаниях.

Тем не менее новые веяния начинают вторгаться в сферу бюджетирования и контрактования через продвинутых «топов» и владельцев компаний, которые по существу своей работы обязаны следить за подобными трендами, ведь именно они позволяют компаниям оставаться лидерами отрасли.

Проблемы локальной оптимизации давно известны, и кто-то уже сполна смог почувствовать их на себе. Смысла налаживать процесс в отдельно взятом структурном подразделении нет, ведь, как сказал один мой коллега: "суперкар с колесами от телеги все равно будет ехать со скоростью и возможностями колес от телеги". Поэтому если основные направления компании работают или только начинают работать в соответствии с гибкими подходами, есть смысл параллельно проводить соответствующие изменения и в финансовом блоке.

В каждой компании, с которой мы работали и работаем (от крупнейших широко известных банков и масштабных IT-организаций до локальных производственных компаний и организаций с государственным участием), данный вопрос остро встает на одном из этапов продвижения к гибкой организации проектной деятельности и процессов. Так как на определенном этапе разрыв между особенностями производства и текущей организацией процессов начинает приводить к потере прибыли, а иногда к убыточности целых бизнес-направлений.

Итак, если вы уже вступили на путь гибкой организации деятельности, вот краткий ликбез поэтапной трансформации финансовой функции компании.

Этап 1. Изменение образа мышления.

Первый этап трансформации, на мой взгляд, самый основной и самый трудный. Инициаторам процесса необходимо донести, а остальным необходимо понять, что есть иная реальность. Важность понимания основополагающих целей компании, командной работы, визуализации, фреймворков. Это все кажется неважным на стабильном и почти всегда серьезно регламентированном пути финансистов и закупщиков.

Тем не менее трансформация - это изменения. И, как и любые изменения, они заставляют людей выйти из зоны комфорта. Это всегда сложно. Не каждый на это решится. Здесь важно прежде всего четко понять цели изменений, результат, к которому хотим прийти и границы применимости.

Исходя из моего опыта и опыта коллег, на данном этапе около 10-20% работников выходят из игры по причинам непринятия подобного подхода к организации деятельности.

Этап 2. Получение знаний.

Для технической трансформации финансовых процессов необходимо полное погружение в гибкие подходы. Ведь организация работы в соответствии с agile-принципами влияет, по существу, на все финансовые процессы: от особенностей формирования бюджета до принципов приемки товара, работы или услуги.

Для качественной трансформации необходимо подробно изучить ценности, принципы, фреймворки и инструменты Agile, углубиться в Lean, понять особенности работы смежных подразделений (например, если они работают в соответствии со scrum-методологией), ознакомиться с обширным зарубежным релевантным опытом и опытом российских компаний.

Необходимо отметить, что этап 1 и 2 в этой структуре вполне могут меняться местами. И изменение мировоззрения, и инициация изменений в финансовом блоке могут происходить после получения лицами, принимающими или инициирующими решения объема знаний, необходимого для принятия решения о новом пути.

Этап 3. Формирование видения изменений (vision).

Изменения не могут быть ради изменений. У изменений всегда есть причины, цели и содержательная сторона.

Важно понять:

  1. Зачем мы что-то меняем,
  2. Что мы меняем,
  3. Кто будет задействован в изменениях,
  4. На кого эти изменения могут повлиять,
  5. Как изменения повлияют на людей, процессы,
  6. Каким образом мы будем реализовывать эти изменения.

После того, как на все вышеуказанные вопросы будет получен ответ, останется только начать реализовывать изменения.

Обычно в формировании видения участвует руководство и подразделения компании, которые прямо или косвенно будут задействованы в процессе изменений. Сложность на первоначальных этапах состоит в обеспечении должного уровня подготовки и фасилитации проводимых Agile-мероприятий. Целесообразно воспользоваться услугами профессионалов в этом случае, которые в дополнение ко всему смогут повысить уровень знаний и практического опыта вовлеченных в трансформацию сотрудников.

Важно также не "заиграться" и обеспечить качественную организацию текущей финансовой деятельности (формирование финансовой отчетности, обеспечение налогового цикла, работы казначейства и пр.).

Этап 4. Начало реализации процессов изменений в рамках пилотного проекта.

Agile-трансформация финансовой функции компании затрагивает:

  1. Процессы бюджетирования,
  2. Процессы осуществления закупок,
  3. Процессы контрактования,
  4. Процессы исполнения контрактов и формирования отчетности по контрактам.

Идеально, если в каждой из этих плоскостей произойдут преобразования уже в рамках пилотного проекта: будет выделен новый "узконаправленный" бюджетный цикл, открыт новый способ осуществления закупок, сформирован новый типовой контракт (типовые условия контракта), утвержден новый регламент администрирования контрактов и т.д. В этом случае метрические показатели, позволяющие оценить скорость и величину изменений, будут максимально близки к реальным.

По итогам пилотного проекта необходимо обязательно провести ревью и ретроспективу для оценки результатов и получения обратной связи, принятия решения об оптимизации процессов, а также для дальнейшего планирования новой итерации и их масштабирования.

Содержание и результаты изменений должны быть результатом коллаборативных обсуждений и решений высшего руководства и владельцев компании (собственники, акционеры и т.п.), руководителей и лиц, принимающих решения бюджетного, закупочного, правового и отраслевых направлений. Также должны быть задействованы работники проектного направления, специалисты ИТ для цифровизации соответствующих процессов, HR-служба. Подобные мероприятия должны быть четко спланированы, иметь жесткий тайминг и подлежать фасилитации (управлению).

Заключение.

В заключение необходимо отметить, что Agile-трансформация - это долгий путь, требующий существенных материальных и производственных затрат. Изменения финансового блока будут касаться, в том числе, и общей политики компании, особенностей приема на работу и оплаты труда. Изменений потребует ряд локальных актов компании. Нужно быть готовым к тому, что в компании скорее всего произойдут кадровые перестановки. Тем не менее при грамотной реализации процессов трансформации результат будет очевидным. Он будет подлежать измерению. А несоответствие процессов, вызванное локальной оптимизацией, будет устранено.

Этап n...

Важно также понять, что изменения в Agile не имеют конца, как бы это для скептиков печально не звучало. В данном случае простейший циклический алгоритм PDCA (цикл Деминга-Шухарта): планирование-действие-проверка-корректировка является основополагающим.


Денисенко Мария
Эксперт в сфере закупок и финансов



Читать далее
Типичные проблемы классического подхода к управлению финансами и закупками при внедрении Agile
Примеры проблемных ситуаций
Кейс 1.
После запуска Agile-команды выяснилось, что для ряда работ из бэклога нужна редкая и не очень нужная в штате экспертиза (например, data science).
Принято решение привлекать подрядчика. Два месяца занимает согласование проекта RFP, месяц - конкурсные процедуры, несколько недель - согласование и подписание контракта.
Пока шел тендер команда занималась реализацией не самых нужных в данный момент вещей, актуальность задачи по data science уже потеряна, момент упущен - конфликт.

Кейс 2.
Для реализации одного из digital-продуктов собирается смешанная Agile-команда с участием подрядчика. Подрядчика привлекают через контракт Time and Materials.
В ходе работы выясняется, что люди подрядчика, которые начинали работу вынуждены срочно перейти на другой проект, вместо них выводят "Джунов", но аккаут-менеджер старательно выдает их за "Сеньоров" - конфликт.
Сроки запуска продукта сорваны, подрядчик не несет за это ответственности, т.к. он только лишь предоставлял нужных людей по согласованным ставкам - конфликт.

Кейс 3.
Проведен тендер на создание в Agile-режиме "под ключ" MVP одной из продуктовых гипотез с дальнейшим анализом продуктовых метрик и доработкой, выводом на широкий рынок.
Выбран подрядчик, соответствующий требованиям по квалификации и опыту, а также предложивший наименьшую цену.
Через неделю выясняется, что контрагент не может работать по Agile в виду сугубо "водопадных" внутренних процессов, функциональной разобщенности и бюрократии. Как компромиссное решение подрядчик предлагает работать а-ля "спринтами" по 3 месяца.

В работе с клиентами мы неоднократно сталкивались с подобными кейсами.
Звоните, будем рады помочь и Вам.

Читать далее
Гибкий договор
Что же такое Agile-договор? Из каких разделов он состоит? Как учитываются в нем принципы гибких подходов? Как соотнести особенности гибких подходов с законодательными нормами?
Гибкий договор может быть составлен в трех различных вариантах:

Вариант 1. Рамочный договор
Согласно части 1 статьи 429.1 ГК РФ рамочным договором (договором с открытыми условиями) признается договор, определяющий общие условия обязательственных взаимоотношений сторон, которые могут быть конкретизированы и уточнены сторонами путем заключения отдельных договоров, подачи заявок одной из сторон или иным образом на основании либо во исполнение рамочного договора.
Возможно заключение рамочного договора как на оказание услуг, так и на выполнение работ.
Вариант 2. Договор оказания услуг
Согласно части 1 статьи 779 ГК РФ по договору возмездного оказания услуг исполнитель обязуется по заданию заказчика оказать услуги (совершить определенные действия или осуществить определенную деятельность), а заказчик обязуется оплатить эти услуги.
Вариант 3. Договор подряда (на выполнение работ)
Согласно статье 702 ГК РФ по договору подряда одна сторона (подрядчик) обязуется выполнить по заданию другой стороны (заказчика) определенную работу и сдать ее результат заказчику, а заказчик обязуется принять результат работы и оплатить его.

Раздел 1. Термины и определения
Целесообразно ввести в договор раздел "Термины и определения", так как используемые в гибких подходах термины не являются общепринятыми согласно гражданскому обороту, что может затруднить взаимодействие сторон, а также обжалование.
Целесообразно внести:
описание процесса (скрам, канбан)
описание объема (например, если оплата определяется за 1 юзер стори)
описание функционала и ролей Заказчика и Исполнителя (владелец продукта, член команды разработки и т.п.)
и т.п.

Раздел 2. Предмет договора
Предмет договора должен быть равен ценности (цели), которую при его заключении Заказчик должен получить, а не конкретному овеществленному результату.
Имеется несколько вариантов формирования предмета гибкого договора:
Вариант 1. Дискавери. Предмет не известен.

Исполнитель обязуется оказать услугу (выполнить работу) по формированию технических требований по доработке информационной системы "Светлое будущее".
Вариант 2. Предмет не уточнен.

Исполнитель обязуется выполнить работы по Заданию Заказчика, а Заказчик обязуется принять и оплатить работы.
Вариант 3. Предмет известен, но конкретные задачи не стоят.
Исполнитель обязуется выполнить работы по доработке информационной системы "Светлое будущее", а Заказчик обязуется принять и оплатить работы.
Вариант 4. Предмет известен, уточнены направления выполнения работ.
Исполнитель обязуется на основании Заданий Заказчика выполнить работы по развитию информационной системы "Светлое будущее" по следующим направлениям:
1. Разработка, модификация, тестирование ПО;
2. Внедрение, адаптация, сопровождение ПО,
а Заказчик обязуется принять и оплатить работы.

Раздел 3. Срок действия договора
Обычно гибкий договор делается с открытой датой для исключения необходимости внесения изменений в случае изменения сроков исполнения по контракту.
Пример формулировки положения договора.
Договор вступает в силу с даты его подписания Сторонами и действует до полного исполнения обязательств Сторонами.

Раздел 4. Порядок исполнения Договора
В гибком договоре должен быть предусмотрен особый порядок его исполнения (также смотри иные разделы Договора):
- обязательные частые поставки (приемки) результата,
- работа по запросам Заказчика,
- тесное взаимодействие Сторон.
Пример формулировки положения договора. Работа по Заданиям
Заказчик направляет в адрес Исполнителя Задание, содержащее требования к работам, описанные в функциональных/технических спецификациях, с указанием состава и результатов работ.
Все Задания, подписанные в рамках исполнения Договора, вступают в силу с момента их подписания Сторонами и являются неотъемлемой частью Договора.
Пример формулировки положения договора. Частая поставка
Исполнитель проводит демонстрацию результата работы по итогам выполнения Задания не позднее 2 (двух недель) с даты его подписания.
Пример формулировки положения договора. Тесное взаимодействие сторон
До начала работ по Заданию Заказчик и Исполнитель согласуют перечень лиц, ответственных за организацию работ по Заданиям (Заданию). Ответственные лица Исполнителя и Заказчика должны быть доступны по следующим средствам связи: телефон, мессенджеры и пр.
До начала работ по Договору Стороны согласуют перечень лиц, обязательных к присутствию на следующих мероприятиях: планирование бэклога продукта, планирование спринта, демонстраци.

Хотите узнать больше?
Приходите на тренинг "Agile-финансы: бюджеты, тендеры и контракты".


Читать далее

© 2018 ScrumTrek
finance@scrumtrek.ru
+7 985 185 35 87
Иван Дубровин
Москва, Путейский туп., д.6