Эволюция в цифровизации: как из «ничего» реализовать продукт, достойный «1С:Проект года»

Меня зовут Алексей Котлов. Я айтишник, работаю на предприятии «ОКБМ Африкантов», входит в машиностроительный дивизион ГК «Росатом».

Мой опыт работы с 1С – с 2010 года, занимаюсь разработкой, развитием и внедрением 1С на предприятии. Работал по направлениям: бухгалтерский учет, налоговый учет, бюджетирование, управление проектами и различные управленческие процессы. Как раз автоматизация управленческих процессов – это то, чем я занимаюсь в первую очередь.

О предприятии

Немного про предприятие АО «ОКБМ Африкантов». Это центр атомного машиностроения Нижнего Новгорода, мы занимаемся разработкой различного оборудования для реакторов.

Одна из последних разработок ОКБМ, о которых вы могли слышать – плавучий энергоблок «Академик Ломоносов». И весь ледокольный флот, который используется в Российской Федерации – это тоже разработки ОКБМ.

Важный аспект предприятия – численность сотрудников.

• Всего в компании работает примерно 4,5 тысячи человек.

• Из них 1600 человек работают непосредственно на производстве – большинство оборудования для наших разработок мы изготавливаем собственными силами.

• Годовая выручка составляет примерно 25 миллиардов рублей.

На предприятии есть собственный ИТ-блок, состоящий из трех подразделений.

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

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

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

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

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

Расскажу про автоматизацию проектной деятельности нашего предприятия, и доклад начну с конца – покажу последнюю информацию по работе используемого у нас проектного модуля «1С:УПО».

• Я уже сказал, что выручка предприятия – 25 миллиардов в год. При этом вся работа по получению дохода у нас организована на основе проектной деятельности.

  • Ежегодно предприятие реализует 350 проектов, и они все заносятся в систему.

  • Для мониторинга и контроля проекты детализируются до уровня работ – итого в системе зарегистрировано примерно 130 тысяч работ.

• Одновременно с нашим проектным модулем работает 300-500 пользователей:

  • из них 100-150 – это менеджеры проектов, которые непосредственно вносят данные в систему;

  • 1200 – пользователи, которые вносят фактические данные и отчитываются о работах;

  • и 50 человек – пользователи экономических отделов (отдел цен, ПЭО, ПДО).

Это только проектный модуль. А в целом с 1С у нас работает примерно 2500-3000 пользователей.

Стартовые позиции

Теперь немного о ситуации на старте внедрения системы управления проектами.

Бухгалтерский и налоговый учет уже были автоматизированы в системе «1С:УПП», и при ее внедрении мы проделали достаточно большую работу по описанию бизнес-процессов – провели несколько предпроектных обследований, составили «талмуд» с описанием процессов на бумаге и в электронном виде. В ходе обследования все сотрудники с этой документацией хорошо ознакомились.

Однако, у нас оставалось множество управленческих процессов, автоматизированных в устаревших системах, таких как Clipper, Excel или DOS. И несмотря на то, что компетенций в компании было достаточно, по этим неохваченным автоматизацией процессам возникали сложности с постановкой задач – у нас отсутствовало понимание, куда двигаться.

При этом как внешние, так и внутренние факторы подталкивали нас к изменениям – и новые требования заказчика, и внешние запросы по изменениям в отчетности, и требования налогового законодательства, положение о военной приемке и так далее. Все это нужно было автоматизировать, и объем этих запросов был достаточно большой.

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

Было множество разнообразных задач, но не было единого вектора развития. И заказчик не пытался организовывать нашу работу – у нас был некий виртуальный заказчик, и нам приходилось под эти условия подстраиваться.

Решение. Описание бизнес-процессов и упорядочивание хаоса

Расскажу про наш опыт – как мы выходили из этой ситуации. Этот опыт включает в себя два основных ключевых направления.

Первое, что нам помогло – то описание бизнес-процессов, которое было составлено в рамках предпроектного обследования при внедрении УПП. Это описание дало нам несколько плюсов:

• Понимание, как вообще сейчас происходит процесс – кто, в какой последовательности, что, когда и как делает.

• Картину в целом – на слайде, например, показаны верхнеуровневые блоки управления проектами на предприятии. Дальше они детализируются, и описав это все, вы представляете картину по управлению проектами в целом.

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

Имея описание бизнес-процессов, мы эволюционно пришли ко второму варианту упорядочивания хаоса, в основу которого легли методология и стандарты управления проектами.

Этот второй вариант состоял из трех ключевых составляющих:

• Обученные пользователи и персонал, который умеет работать.

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

• Методология.

Причем методология появилась не с осознания того, что она нам нужна, а с проблематики возникновения запросов на автоматизацию. Мы увидели, что запросы в основном возникали по следующим причинам:

• Требования внешних сторон – например, необходимость соблюдения положений о военной приемке. Или требования международных заказчиков, которые тоже основаны на определенных стандартах и нормативах.

• Проектные команды работали, как получится, «кто во что горазд» – кто как представлял себе устав или график проекта, тот так его и делал.

• Нам приходилось постоянно подстраиваться под новые требования – дорабатывать и кастомизировать систему. Люди говорят: «Хочу!» – мы делаем. Такая постоянная кастомизация требовала большое количество ресурсов, времени и вообще разбирательства, что надо делать.

Пилот №1

Как мы пришли к формированию методологии.

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

Первый «пилот» заключался в том, что мы пошли от наиболее злободневной задачи, которая забирала дикое количество ресурсов – учет дебиторско-кредиторской задолженности. Проанализировали эту задачу и поняли, что для системной реализации можно подключить проекты. Тем более, что расчет идет по заказам, а заказ – это этап нашего проекта.

Чтобы решить эту задачу, сделали несколько ключевых шагов:

• Изменили учетную политику – сделали этап проекта равным заказу покупателя. Раньше каждый мог открыть этап проекта так, как хотел.

• Обеспечили занесение графика платежей и графика поставок в привязке к этапам проекта (заказам покупателя). И сделали это удобно.

• И уже как следствие – произвели доработку системы и обучили пользователей.

Таким образом мы добавили в систему аналитичность и на выходе получили модуль, позволяющий:

• вести в системе проекты;

• привязывать этапы проектов к заказам;

• формировать графики платежей;

• формировать графики поставок.

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

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

Пилот №2

После этого пошли немного дальше, но теперь уже отталкивались не от задачи, а от потребностей «человека с погонами» – нашего генерального директора.

Он постоянно пользуется инструментом, который называется тематический план. Это отчет, который содержит данные по годовой, трехгодовой и десятигодовой выручке предприятия. С его помощью удобно производить стратегическое и оперативное планирование, мониторинг и контроль всего, что происходит на предприятии.

Раньше генеральный директор анализировал этот тематический план в бумажном виде – ему собирали, печатали, приносили, и он это смотрел. Мы убедили генерального, что можно получать данные из системы, проработали с ним вопрос, каким образом это будет происходить.

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

Здесь получились немного другие шаги внедрения:

• Мы проработали нормативную базу – внесли обязательность занесения данных в систему приказом по предприятию.

• Договорились с директором, что если в системе данных нет, то руководитель их не предоставил, или они неверны: «Нет в 1С – нет в жизни».

• И на своих ежедневных оперативках генеральный директор получал эти данные только из системы.

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

Кроме этого, насытили систему дополнительными инструментами для анализа ситуации. Например, сделали сравнение, из какого периода в какой «уехала» выручка, почему, и кто ответственный. Для директора стало еще удобнее.

Таким образом, помимо добавления функциональности, мы еще и вовлекли топ-менеджмент и руководство предприятия в то, чтобы работать в системе с этими инструментами.

Бесконечный Agile

У нас это получилось, нам это понравилось, и мы такой подход решили продолжить.

Брали небольшую злободневную задачу либо задачу, в реализации которой заинтересован топ-менеджмент, и последовательно шли по следующим шагам:

• определение потребности;

• написание технического задания;

• формирование технического решения;

• реализация;

• инструкции и обучение пользователей;

• и внедрение – все стандартно.

В результате мы наработали кучу таких небольших модулей. Например, после двух пилотов мы сделали:

• формирование исходных данных проекта;

• расчет цены, который делался на основании этих исходных данных;

• расчет бюджета управленческой себестоимости проекта;

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

Это получилось сделать силами шести человек: РП, архитектор, 2 аналитика и 2 разработчика. Но надо понимать, что сроки были достаточно длинные – я не зря говорю, что внедрение системы у нас длится с 2010 года.

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

IPMA как панацея. Функциональные области

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

Смотрели нескольких вариантов:

• PMI – западный стандарт, и мы от него по этой причине отказались.

• Стандарт ГОСТ Р 54869 – 2011 Проектный менеджмент – он на тот момент оказался недостаточно проработан.

• И НТК – это российский национальный стандарт, разработанный на основании международного стандарта IPMA российской компанией «СОВНЕТ». Он оказался золотой серединой.

Опираясь на рекомендации НТК мы:

• Стандартизировали процесс проектного управления – там есть некоторые стандартные процедуры, стандартные положения, стандартные предметные области и так далее.

• Централизовали функцию проектного управления – до этого у нас пользователи работали в множестве отделов, в каждом из которых были свои менеджеры проектов. Мы объединили несколько отделов согласно производственным тематикам, и унифицировали их процессы.

• Добавили контрольные процедуры в проектах и в процессах.

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

• зеленым цветом на схеме закрашены те области, где все сделано хорошо;

• желтым – где нам еще надо поразвиваться.

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

Следующая контрольная процедура отвечает за долготу или фазы жизненного цикла проекта – об этом тоже говорится в стандарте.

На слайде я наложил модули системы, которые мы реализовали, на фазы проекта.

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

Эффекты от внедрения

Эффект, который мы получили от внедрения. Слайд взят не из воздуха – он готовился для премии «1С:Проект года», которая требует подтверждения каждого из показателей.

Здесь проценты получены либо экспертным путем, либо взяты из методологии – мы оценивали затраты до внедрения какого-то цифрового инструмента и после. Например, когда мы внедряли электронное согласование для документов, измерили, сколько времени занимало согласование на бумаге, и сколько времени занимает электронное согласование.

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

Извлеченные уроки

Немного о выводах, которые мы сделали по результатам автоматизации у нас проектного управления:

1. Управленческие процессы всегда отличаются достаточно большой степенью неопределенности – как со стороны заказчика, так и со стороны процедур. Они имеют совершенно размытые требования, размытые сроки, размытую ответственность и так далее. Они всегда недостаточно регламентированы, а иногда – вообще не регламентированы. И когда мы приступаем к автоматизации таких процессов, к этим проблемам нужно быть готовым.

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

3. При применении «эджайл» важно, чтобы кто-то четко понимал вектор развития – куда ведут те маленькие этапы, которые мы создаем, как мы будем двигаться вперед и что в конечном итоге нам нужно. Потому что когда мы начали раскручивать каждый из блоков внедрения проектного управления и разбираться, как они связаны между собой, мы в какой-то момент запутались с общей картиной.

4. Можно очень хорошо поработать с заказчиком. Как показывает пример нашего генерального директора, заказчика можно заинтересовать, даже если его нет. Мы этот подход использовали на заместителя генерального по финансам и на одном из главных конструкторов. Если человека заинтересовать, показать, что ему будет быстро и хорошо работать, процесс у вас получится – он будет заинтересован, и будет вам помогать. То есть можно пойти не снизу, а сверху.

5. В связи с этим и схема внедрения может быть разная. С одной стороны, мы можем пойти последовательно – разработать методологию, написать ТЗ, разработать техрешения. А с другой стороны, можно сразу пойти с цифровых инструментов, показать, как это работает, и тогда люди будут вовлекаться сами. У нас так тоже получалось.

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

1. Если вы автоматизируете «живой» процесс, по которому есть ответственные и полное понимание, как и в какие сроки он проходит. В этом случае вы можете его оцифровать и получить результат в информационной системе – как правило, этот результат будет получаться быстрее, чем до автоматизации.

2. Если вам будет помогать человек, который наделен полномочиями, может заставить работать других и заинтересован в вашем результате. Я рассказывал про пример, где генеральный был заинтересован. Но у нас есть примеры процессов, где генеральный не был заинтересован, и ничего не получилось. Но вы можете найти другого человека. У нас был хороший пример с ЗГД по финансам, когда мы автоматизировали получение бюджета по ДДС. Там тоже «человек с погонами» заставил всех вносить данные, и бюджет в системе стал появляться вовремя.

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

Вопросы и ответы

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

Поскольку мы в штате и занимаемся собственной разработкой, наш бюджет – это зарплата.

О бюджете можно вести речь, когда мы собираемся покупать новый продукт или ищем внешнего подрядчика, который будет нам дорабатывать систему. Но с подрядчиком мы по эджайл в принципе работать не можем.

Но ведь бывает такое, что поставлена задача, а на этапе ее реализации вам говорят: «А давайте вот так?» а потом: «А давайте еще и вот так?» Это же деньги.

Опять-таки мы в штате, и у нас денег по своим проектам нет. У нас это в основном сроки, не деньги. Причем есть ситуации, когда различные заказчики говорят один и тот же срок, и нам приходится совместно с ними эти сроки приоритизировать.

Здесь вопрос не столько в бюджете на штат, а в бюджете на само выполнение проекта, куда может входить и дополнительное ПО, и железо.

Подобные проекты мы выполняем по другой схеме. Например, у нас сейчас есть проект импортозамещения, мы переводим MS SQL на PostgreSQL. Мы не уверены, что у нас получится эффективно реализовать этот проект с точки зрения работы самого сервера, поэтому мы выходим на подрядчика и ищем франчайзи с опытом.

Конкретно на этот проект у нас запланировано 10 миллионов. И тут вопрос договоренности и инвестиционного бюджета. У нас сложная система закупок, и это вообще отдельная история. Мы – «Росатом», и простых путей не ищем.

А в годовой тематический план попадают перспективные проекты?

Конечно. В тематическом плане отображаются все проекты, которые введены в систему. Даже те, которые планируются на 2030-2040-е годы – по ним тоже можно сформировать график платежей и график поставок. Просто у них будет статус «Проект-видение» – мы его так назвали.

Тематический план – это как раз инструмент стратегического планирования. Директор там видит проекты на 10, 20, 30 лет вперед. Там нет ограничений, вопрос только во вводе данных.

Вы говорили, что вовлекли в работу с системой одного из главных конструкторов. Чем именно вы его привлекли в системе?

Главный конструктор постоянно сталкивался с тем, что производство не выполнялось в срок. А поскольку у нас НИОКР, серийки нет, производство штучное, мы производство запускаем блоками, когда конструктор понимает, что и в каком объеме ему вообще нужно сделать.

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

У главного конструктора с этим процессом постоянно была куча проблем. Мы ему предложили позаниматься. Сначала он с нашей помощью заставил вносить данные в систему по своему направлению, а потом мы это тиражировали на все предприятия.

Т.е. у него были проблемы, мы сказали, что можем помочь, и у нас все получилось.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.