Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Меня зовут Гюльнара Антропова, и я хочу рассказать про технологию автоматизации, которую мы используем в наших проектах.

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

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

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

• Есть опыт автоматизации типовых конфигураций без единой доработки.

• Есть опыт автоматизации с внесением существенных изменений в типовые конфигурации.

• Есть опыт, про который я вам сейчас хочу рассказать – когда мы не меняем типовую конфигурацию, но выполняем 98% противоречащих друг другу требований заказчика.

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

• В 2017 году у меня был очень значимый проект в Газпроме Республики Башкортостан. Там под моим руководством и при моем участии была с нуля разработана автоматизированная система управления имуществом. Чтобы вы понимали, имущество – это все газопроводы и оборудование республики. У нас получилось оцифровать объекты таким образом, что информация со всех видов учета – регламентированная, производственная и имущественная – собиралась в единую картину.

Именно на проекте внедрения системы управления имуществом в Газпроме РБ мы и пришли к той технологии, про которую я вам сейчас хочу рассказать. Потому что из 600 человек пользователей, которые оцифровывали всю информацию по этим газопроводам, 550 человек были производственными рабочими. Это люди, которые не только с 1С никогда не работали, они и компьютером-то толком раньше не пользовались. Поэтому нам нужна была такая система, в которую люди в правильном порядке будут вводить сложнейшую, разную информацию, не ошибаясь. И мы такую систему сделали при помощи той технологии, про которую я хочу рассказать.

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

Продолжая рассказ о себе, моя фишка в том, что я:

• владею технологией построения и оптимизации процессов;

• имею практический опыт делать это;

• умею подбирать инструменты автоматизации так, чтобы процессы разработки и внедрения работали на системном уровне;

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

Почему нам потребовалось менять общепринятую технологию автоматизации?

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

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

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

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

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

• Продукцию мы действительно будем выпускать с учетом потребностей заказов.

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

• И еще нам надо понимать, что узлы и подузлы производятся заранее и лежат на складе – на это количество нужно скорректировать количество к запуску в производство.

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

Когда нам это рассказывают, нам кажется, что это какой-то противоречивый бред. На самом деле вполне нормальная логика.

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

Здесь появляются две задачи:

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

• Или участок сборки у нас не-дозагружен, и нам нужно искать, чем его до-загрузить.

•  

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

• собственным производством – это своя цепочка процессов;

• и внешним производителем – это совершенно другая цепочка процессов.

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

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

Почему нам не подходит типовой вариант – когда мы описываем процессы «как есть» и «как будут», разрабатываем и внедряем?

• Первый этап – описываем процессы «как есть». Получаем противоречивую информацию о процессах, неполную. Мы понимаем, что она неполная. Но мы при этом даже не подозреваем, насколько она неполная. Хорошо. Описали, этап закрыли, все нам подтвердили.

• Следующий этап – начинаем моделировать. На этапе моделирования у нас две «бомбы замедленного действия».

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

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

• Дальше мы настраиваем, разрабатываем.

• Приносим внедрять, и начинается: «Вы все не так сделали!» – «Почему не так? У нас же все записано – вы так говорили!». На что получаем аргумент, который мне больше всего нравится: «Да, мы так говорили, но думали, что будет не так». Ну тут уже «против лома нет приема».

«У нас еще несколько принципиальных требований к автоматизации» © Заказчик

К этому добавляется несколько принципиальных требований от Заказчика:

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

• Заказчик говорит: «Сделайте нам такую программу, которая нас заставит работать как надо». Казалось бы, есть инструкция – пусть ваши люди работают по инструкции. Но если программа позволяет выполнить пятый шаг, не выполнив первые четыре, независимо от инструкций и регламентов, первые четыре шага выполнять никто не будет – это естественно.

• Заказчик просит: «Сделайте так, чтобы мы от разработчика не зависели». Но мы же показали, что эти требования типовыми средствами не решить. Получается, что нужно ломать типовую. А если разработчик начнет ломать типовую – лучше вам с этим разработчиком не расставаться, это наш хороший совет.

• Заказчик: «Мы не хотим менять типовую, нам не нужны проблемы с обновлениями». Ну как это сделать-то?

• И прям вишенка на торте: «Мы хотим поменять в системе все, не останавливая ее работу, «на лету». Недавно один акционер сказал нам интересную вещь: «Мы сейчас едем на пассажирском поезде, а к концу проекта хотим ехать на Сапсане, не заезжая ни в какое депо на ремонт».

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

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

Суть технологии

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

• Первое – мы не трогаем типовую, мы разрабатываем надстройку над типовой в виде надсистемы.

• Эту надсистему можно настроить под конкретные особенности деятельности каждой компании с учетом конкретных этапов и операций для конкретных бизнес-процессов.

• Надсистема содержит:

  • внешние обработки – то, что мы называем рабочими местами;

  • структуру данных для того, чтобы сами обработки могли работать;

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

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

  • отражают в системе все необходимые операции и выполняют все необходимые действия с данными;

  • создают все необходимые типовые документы;

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

• Этот подход помогает нам последовательно автоматизировать отдельные процессы и функции: один шаг автоматизировали – переходим на следующий шаг.

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

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

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

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

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

Сквозной процесс. Формирует границы полной надсистемы

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

Опишу вам сквозной процесс выпуск продукции крупными этапами:

• Процесс выпуска продукции начинается с планирования. Результат планирования – это некая потребность.

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

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

• Дальше у нас формируется партия, она поступает на контроль,

• И после контроля у нас появляется годная и негодная продукция, которая поступает на склад.

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

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

• На выходе «Рабочего места Планирование производства» появляется документ «План производства» по определенному сценарию.

• На выходе «Рабочего места Диспетчера» появляется вся цепочка производственных документов в нужных статусах.

• «Рабочее место Мастера» закрывает все эти документы,

• А «Рабочее место Контролера» мы реализовывали в своей надстройке, потому что в типовой конфигурации этой функциональности нет.

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

Этапы разработки надсистемы у нас тоже отличаются от типовых этапов:

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

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

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

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

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

• Второй этап – разработка MVP версии.

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

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

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

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

Матрица процессов. Это список процессов + связи между процессами

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

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

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

Дальше для каждого вида деятельности составляется список процессов.

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

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

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

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

Карта путешествия пользователя – дорожная карта разработки Рабочего места

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

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

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

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

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

Фишка этой карты путешествия пользователя в том, что:

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

• Дальше, когда мы разрабатываем MVP-версию, этот порядок становится сценарием тестирования – т.е. MVP-версия должна позволить выполнить все шаги из порядка работы пользователя. В процессе разработки мы этот порядок при необходимости корректируем. Получается, что нам, по сути, не нужно писать инструкции. Благодаря этому подходу сотрудники заказчика сами тестируют, сами говорят, где что нужно добавить, удобно им это или неудобно и т.д.

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

Этот инструмент позволяет вовлечь сотрудников заказчика на ранних этапах проекта и снимает очень большие риски.

Технология, доведенная до совершенства, практически неотличима от магии

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

При помощи этой технологии вы можете:

• Расширить рынок продаж своих продуктов. Эта технология позволяет идти в те проекты, где, например, у вас нет опыта, или есть большие риски, что что-то не получится. Потому что на первом шаге причесываются все потребности, все требования для выполнения второго шага. Здесь нет такого, что надо сразу всего этого слона описать, все сделать, а потом героически переделывать.

• Снизить трудозатраты на разработку.

• Снизить трудозатраты на внедрение и повысить качество работ.

• Сократить время и трудозатраты на доработки, потому что все происходит по фактическим данным. Мы ничего не придумываем. Нам заказчик говорит: «Здесь надо поменять на это» – пожалуйста, меняем.

• Ну и повысить доход от проекта.

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

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

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

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

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

Чтобы сейчас перейти на четвертый уровень, вы обязательно должны начать это использовать, и у вас обязательно должны появиться вопросы.

Поэтому спрашивайте, уточняйте, используйте!

Вопросы

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

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

На скольких проектах эта технология вами использовалась? «Газпром» только? Или где-то еще?

Мы использовали эту технологию на проекте «Газпрома». Потом в производственной компании, которая производит автосигналы для спецмашин. И в производственной компании, которая производит пожарную сигнализацию.

Всего – в трех компаниях с многопередельным производством.

Я правильно понимаю основную идею, что вы не трогаете типовую функциональность, вы разрабатываете интерфейсные части для каждого участника игры, для каждого пользователя, который в этом работает? Если сущность действий человека в интерфейсе совсем не соответствует той логике, заложенной в рамках ERP, вы все равно ищете какие-то сущности, на которые опираетесь в рамках типовой?

Я считаю, типовая 1С:ERP – замечательный продукт. В ней есть очень хорошая разветвленная система хранения информации.

Вы говорите, что мы не столкнулись с такими вещами, которые нельзя типовыми реализовать. Но я специально вначале много времени потратила, описывая тот процесс, который мы автоматизировали – его типовыми средствами автоматизировать нельзя, вообще нельзя. Процессы, которые мы автоматизировали в трех проектах, не решаются типовыми средствами 1С:ERP вообще никак. Тем не менее у нас получилось это решить.

Но каждый конкретный случай опять-таки надо разбирать.

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

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

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

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

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

Я просто утрировал ситуацию. Но почему вы считаете, что текст удобнее?

Текст понятнее заказчику. Мы с ним разговариваем на одном языке. И поэтому, когда мы ему приносим готовое, у него не возникает вопросов: «Я думал, что будет не так».

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

Что делать с вашей технологией, если процессы заказчика сложились настолько давно, и они настолько запутаны, что пользователи сами до конца не могут вам помочь их описать?

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

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

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

А потом все это складывается просто как пазл. Вы просто не знали, что так можно, но так можно – хотя дальше еще надо разбираться.

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

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

Если это можно сделать типовыми средствами, это понятно и логично, мы там рабочее место не делаем.

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

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

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

И дальше то, что можно делать типовыми.

Если я эти регистры заполню руками, у меня система точно так же будет работать?

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

Получается, чтобы проверить работоспособность рабочего места, я должна провести все эти манипуляции?

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

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

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.