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

По данным исследования Deloitte 36% руководителей считает фрагментарные процессы главнейшим барьером для масштабирования автоматизации. Вендоры стараются сделать максимально простым и бесшовным процесс взаимодействия человека с RPA-системами, выстраивая оптимальную архитектуру своих решений. Таким образом можно значительно упростить автоматизацию длительных процессов, требующих участия человека.

В статье мы расскажем:

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

- как в эту работу вовлечь бизнес-пользователей, когда это необходимо,

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

Начнем с реального примера.

Кейс страховой компании: как с помощью RPA достигнуть эффективности в 122 ПШЕ

Крупная страховая компания России обрабатывает более 24 тыс. договоров в день. Для этих целей в компании был создан операционный центр, который принимает договора от агентов и заносит данные договоров в базу. Роботизация в компании началась как оптимизация работы центра. Компания планировала перенести на операционный центр дополнительные функции, не увеличивая при этом численность персонала. Для этого была поставлена задача автоматизации текущих задач центра. Для успеха проекта достаточно было автоматизировать 100 ПШЕ (полных штатных единиц), этих ресурсов хватало на выполнение дополнительных функций.

Проект по роботизации начался в компании в 2017 году и за это время удалось всего на трех процессах (один из которых обработка поступающих договоров страхования) достичь эффективности в 122 ПШЕ. Роботы помогают сотрудникам центра обрабатывать гораздо больший объем документов, снизив вероятность ошибок до минимума. Сегодня в компании полностью автоматизированы обработка и учет договоров страхования, а также процесс по поиску убытков.

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

Обработка одного договора человеком занимала 5 минут, у робота это занимает чуть больше 1 минуты.

Роботы работают на 80% быстрее человека, а 70% всех задач они выполняют без его участия. Окупаемость роботизации всех трех процессов составила 8 месяцев.

Что под капотом: техническая реализация оркестровки

Кейс, приведенный выше, является примером автоматизации фрагментированных процессов, то есть процессов, которые разделены на этапы и требуют участия человека между этими этапами. Для описания таких процессов также используется термин human-in-the-loop. Автоматизация фрагментированных процессов достаточно новая функциональность для RPA-систем. В решениях UiPath она стала доступна с появлением Action Center. Робот, столкнувшийся с каким-либо бизнес-исключением или ошибкой, может создать задачу пользователю и отправиться выполнять другие задачи. После того, как человек даст свой ответ, первый свободный робот продолжит выполнять процесс. Рассмотрим упрощенный пример того, как автоматизация таких процессов может быть реализована. Мы создали простой процесс приема и обработки страхового договора. Документ поступает на вход, сотрудник извлекает из него данные и принимает решение, требует ли этот договор согласования. Если договор удовлетворяет формальным требованиям, он заносится в учетную систему. Этот пример является довольно простым для роботизации, сложности возникают, когда приходится обрабатывать большое количество таких договоров.

Мы предлагаем решать задачу обработки большого количества документов в процессах human-in-the-loopс помощью процесса оркестровки, который проверяет что именно происходит с интересующими нас объектами. Изобразим наш пример на схеме, процесс состоит из четырех этапов:

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

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

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

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

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

Список задач для роботов выглядит следующим образом:

В нашем случае работают 2 робота, они берут задачи из списка на выполнение. На скриншоте нижний процесс InsContract_Main и есть наш процесс оркестровки. Он стоит на паузе, ожидая, пока какой-нибудь из элементов очереди обновится. На вход поступили 10 документов, соответственно добавилось 10 элементов в очередь, и на каждый элемент инициировался свой процесс InsContract_DU - распознавание и извлечение данных. Как мы видим, 4 таких процесса уже успешно завершилось, два документа из четырех не требуют согласования, и поэтому процесс оркестровки создал две задачи InsContract_EnterApprovedContract - процесс заведения договора в учетную систему, мы видим их первыми на экране.

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

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

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

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

Пример отчета:

Как это было разработано?

Для реализации этого примера мы использовали активности из блока Long Running, они созданы специально для работы с фрагментированными процессами:

При отправке элемента в очередь мы использовали активности Add Queue Item And Get Reference/Wait For Queue Item And Resume.

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

Для создания задач по вводу данных в учетную систему - Start Job And Get Reference/Wait for Job and Resume.

Для создания задачи для человека в Action Center Create Form Task/Wait For Form Task and Resume.

Для параллельной обработки всех документов активность Parallel For Each.

Часть процесса оркестрации выглядит следующим образом

Итоги

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

Для будущих студентов курса BPMN: Моделирование бизнес-процессов подготовили полезную статью, автором которой является Наталия Желнова преподаватель курса .

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

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

Часть 1. Зачем люди моделируют бизнес-процессы

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

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

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

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

Цифровизация, цифровая трансформация компаний, как в государственном, так и в частном секторе, так же невозможна без построения бизнес-модели, как и любая другая трансформация бизнеса. Подобная практика не просто дань цифровой моде, задаваемой высокотехнологичными компаниями; она опирается на мировые стандарты. Наличие документированной бизнес-архитектуры предприятия является требованием международных стандартов ISO 9001:2000 и российских стандартов ГОСТ Р ИСО 9001-2001. Проверенные на практике подходы рекомендуют придерживаться определенного порядка построения бизнес-архитектуры. Без предварительного моделирования изменений в бизнес-процессах и оценки эффектов этих изменений невозможно определить количественные и качественные результаты трансформации, оптимизировать расходы в процессе трансформации.

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

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

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

Определение 1. Бизнес-процесс совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы (ISO 9000:2000).

Определение 2. Бизнес-процесс структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).

Определение 3. Бизнес-процесс совокупность различных видов деятельности, в рамках которой на входе используется один или более видов ресурсов, и в результате этой деятельности на выходе создается продукт, представляющий ценность для потребителя (М. Хаммер, Д. Чампи, Реинжиниринг бизнес-процессов).

Определение 4. Бизнес-процесс несколько связанных работ или процедур, в совокупности реализующих конкретную цель текущей деятельности в рамках существующей оргструктуры (Ойхман Е.Г., Попов Э.В, Реинжиниринг бизнеса).

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

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

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

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

• Бизнес-аналитики по различным направлениям деятельности организации;

• Разработчики информационных систем;

• Системные архитекторы, разрабатывающие архитектуру отдельных информационных систем;

• Бизнес-аналитики, выполняющие проектирование организационной структуры предприятия;

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

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

Узнать подробнее о курсе BPMN: Моделирование бизнес-процессов.

Записаться на открытый урок по теме Введение в моделирование бизнес-процессов.

Забудь дедукцию, давай продукцию, эту формулу я усвоил сразу после окончания института. Тогда я ещё был финансистом и мир науки и образования меня буквально выкинул в мир бизнеса. Я ждал матриц, проектных структур, менеджмента строго по Мескону и Хедоури, а получил твою мать, какого х** бюджет не сводится, давай, подрисуй цифирь и отправим это уже главнюкам. Вооот, а это была компания на 120 человек с чистой прибылью в пару сотен миллионов. Это было начало 2008 года, который компания пережила, сократив 23 человека. А вот декабрь 2014-го стал последним месяцем существования всего холдинга. Я, уже большой чувак, понимал, что это всё результат череды управленческих ошибок. К тому времени я работал сисадмином в ИТ-компании и был уверен, что здесь всё будет круто. Сменив три ИТ-компании, я понял, что айтишники при всей инженерной стройности управляют и развиваются без вектора. И знаете, сейчас меня это тревожит.

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

Так что меня тревожит?

Когда у компании нет вектора, она выглядит беззащитной. 2020 год вдарил по многим компаниям с ноги, ИТ-компании пощадил и всего лишь ударил кулаком в грудь. Но это мог быть нокаут.

О каком векторе идёт речь?

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

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

Мы человекоориентированные. Фиг там! Провозглашённая HR-ами человечность разбивается о первый же кризис: если компании нужна оптимизация штата и нужны сокращения, те же улыбчивые девушки из отдела работы с персоналом будут выдавать вам трудовые книжки и прогибать вас под уход по собственному, ведь на любого человека статья ТК РФ найдётся, ты в октябре три раза опоздал.

Мы богатые. Да, многие компании в ИТ по-настоящему прибыльны и богаты. Но почему-то в кризис они начинают оптимизировать всё: от персонала до заработной платы и затрат на питание, тренажёрки и ДМС, потому что они не понимают, сколько им понадобится и когда это закончится. Нет видения на будущее, нет стратегии, поэтому проще всего резать косты и закрывать проекты.

Мы лояльные. Наш офис настоящий социальный объект: правильное питание и фрукты, тренажёры, уголки шахмат и музыки по интересам, живые стены и даже капсульные спальные места. Нет, ребята, спасибо: я лучше залью чайный пакетик кипятком в офисе небольшой компании, где не будут пытаться выстроить конвейер по выкачиванию моего личного времени и удержания на мотивации нигде так не будет. Индексируйте заработную плату, вводите справедливую систему KPI, управляйте моим развитием и тогда я сам чуть дольше задержусь в офисе, куплю мясо и фрукты, отдохну и схожу на танго. К сожалению, лояльность заканчивается при первом же кризисе и вы очень быстро находите поводы избавиться от хорошего, но неудобного сотрудника: токсичный, опоздал, проболел спринт

Мы развиваемся и развиваем сотрудников. Куда вы развиваетесь? А сотрудников как развиваете? Думаете, три билета на конференции и подписка на книги с Amazon (Питер, OZON) это развитие сотрудника? Нет. Развитие сотрудника это чёткое понимание каждого работника, кем он будет в конце года, через два года, через пять. Любой человек склонен планировать и не очень разделяет ванильные статусы про живи одним днём, потому что если пережить один день, потом ещё один и ещё пару недель, приходят платежи за коммуналку, школу, вуз, стоматолога и т.д. И вот тогда хочется очень чётко понимать: моя компания надёжная, она планирует развиваться на рынке AR/VR, есть MVP продуктов и стратегические исследования, я сейчас прямо займусь вопросами инфобеза и через 2 года впишусь в новый проект как DevSecOps. Вот это план развития. И знаю компании, где всё примерно так и работает. Да, они чуть более бюрократизированы и авторитарны, но безусловно надёжны (если сам себе не нагадишь).

И что в итоге получается? Я обмениваю свой мозг, свой опыт на все эти комфортные условия и деньги, но у меня пропадает ощущение собственного развития: я работаю в моменте, меня отжимают, высасывают и в конце концов выбрасывают. И так же происходит с тысячами опытных профессионалов, в то время как они могут расти вместе с компанией и делать её супер сильной и прибыльной. Но нет, мир придумал фигню про срок ротации в пять лет: отработал 5 лет, не вырос, меняй работу. Им выгодно нанять послушную и управляемую молодёжь, и снова начать их ротировать. А вы, дорогие управленцы компании, даёте себе отчёт в том, а компания-то за 5 лет изменилась, чтобы нам в ней вырасти? Или топчется на месте? А вдруг ползёт назад? Ведь прибыль не всегда признак прогресса. Что там по стратегии?

Учат в вузе, учат в вузе и внезапно используют

Моё первое образование очень классный экономический и управленческий вуз. Там просто чумово преподавали менеджмент организации, настолько круто, что я, круглый отличник, ловящий всё на лету, сдал этот предмет на 4, группа на 3 и 4, потому что всё было слишком по-взрослому. Конечно, после экзамена мы пили яблочный и забродивший виноградный сок на набережной, заедали сыром-косичкой и матерно кричали, на чём мы вертели эту преподшу-практика и её Мескона, Хедоури, Друкера, Хонду и канбан Тойоты. Там были матрицы компаний, стратегии по каждому пункту, анализ конкурентов и поиск себя на рынке. Мы рисовали то, что сейчас принято узнавать в магическом квадранте Гартнера, создавали выдуманные фирмы и разрабатывали стратегию. Такая теория. И я думал, что это мне никогда не пригодится.

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

• Матрицы KPI мы все их немного ненавидели, но в целом это была справедливая система ежемесячной оценки труда каждого сотрудника, зависящая от выполнения задач. Были субъективные моменты, но их исключили после нескольких жалоб коллег и совместного обсуждения.

• Стратегия на 1, 3 и 5 лет. Компания и каждый в ней примерно знали точку будущего развития. Поясню на своём примере: я работал в коммерческом отделе, увидел переход на собственные вычислительные мощности, переучился на долгосрочных корпоративных курсах по системному администрированию и разработке, переместился в отдел АСУ, а затем и в разработку. У каждого был шанс на маневры. Всё это оформлялось в виде тех самых матриц и SWOT-анализа, которые мы разбирали на курсе менеджмента в вузе.

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

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

• Отличный самописный корпоративный портал помогал быстро и качественно информировать всех, благодарить коллег, поддерживать нормативную базу и чат (это был самописный чат, один из первых корпоративных). Там же мы пересылали друг другу ТЗ, создавали рабочие группы и проч. Короче, мы изобрели Битрикс до Битрикса и даже круче, но не придали значения этой разработке.

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

• Открытая кадровая политика без агрессивного ассессмента. Внутренние должности, в том числе топовые, замещались из числа сотрудников, на каждую вакансию объявлялись открытые конкурсы с заданиями при определённом подходе можно было прыгнуть выше головы (но если не справлялся с взятой на себя работой, возвращался обратно или ниже без обид).

• Централизованное бюджетирование. Каждое подразделение могло спланировать свои доходы. Благодаря этому отношения с клиентами и партнёрами были более чем нестыдные. Полученный на расходы бюджет положить в карман было нельзя.

Итог

За 5 лет сокращены 3 человека с полными выплатами + 3 оклада сверху, исполнены все бюджеты, компания трижды была ключевым налогоплательщиком региона, успешно пройдены 2 аудита. После продажи и реструктуризации (по инициативе головной конторы) за сотрудников дрался весь узкий рынок. Другие региональные центры просто распустили.

Восприятие

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

Нафига козе баян?

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

Итак, что может дать внятная стратегия?

Устойчивость компании: краткосрочные выгоды уйдут в сферу рутины, большинство ресурсов будут направлены на достижение 1-2 глобальных целей. Главная задача сделать так, чтобы текущие мелкие задачи не замедляли развитие компании в будущем (например, компания на фоне экономического спада сокращает несколько сотрудников, но в скором будущем придётся набирать, обучать и адаптировать новых а это лишние траты и уход с основной оси развития).

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

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

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

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

И вот для всего этого стоит прямо сейчас взять учебник по менеджменту и изучить, как строится управление организацией по хардкору. Я на Хабре не нашёл каких-то особенно глубоких материалов на этот счёт, да особо и не надеялся. Какой-то грустноватый здесь поток Менеджмент, а могло бы быть уууух.

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

Ну что, загрузил я вас или норм?

И было сказано слово: "Маркировка!" И набежали тучи, и застили небо. И повис в воздухе вопрос: "Что делать?" И закралась надежда: "Авось пронесёт!"

Часть 1. Глаза боятся, а руки делают

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

1. Определить Владельца бизнес-процесса "Маркировка" - центр ответственности и Ключевого пользователя - центр компетенций по операциям маркировки товара/продукции.

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

4. Ввести в рабочую группу юриста компании, в задачи которого входит экспертиза нормативной документации по маркировке и отслеживание изменений в правовом поле.

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

6. Разработать план-график запуска процесса маркировки с учетом графика запуска маркировки в отрасли.

7. Сотруднику компании, имеющему право подписи документов без доверенности, пройти процедуру регистрации в личном кабинете "Честного знака" (далее ЛК ЧЗ) . Подключить тестовый ЛК ЧЗ.

8. Выпустить усиленную квалифицированную электронную подпись (УКЭП) с расширением "Маркировка" для Ключевого пользователя и подключить его в рабочий и тестовый ЛК ЧЗ с ролью "Администратор".

9. Выделить 25 - 40 часов Ключевому пользователю по маркировке на изучение нормативной документации, пользовательских инструкций, видео-инструкций и т.д..

10. Настроить интеграцию между тестовой средой ГИС МТ ("Честный знак") и тестовой учетной системой, используя стандартные механизмы.

11. Ключевому пользователю провести функциональное тестирование операций по маркировке. Результаты оформить Протоколом.

12. Разработать схему бизнес-процессов компании и встроить в неё операции по маркировке. Согласовать с участниками рабочей группы.

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

14. Сформировать пул задач на доработку учетной системы компании, в т.ч. по интеграции с ГИС МТ. В зависимости от имеющегося в распоряжении времени установить задачам первый или второй приоритет, разработать график реализации.

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

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

17. При наличии технических и производственных возможностей выполнить пилотный запуск процесса маркировки.

18. Подготовить инструкции для пользователей, при необходимости провести обучение. Подключить пользователей в рабочий ЛК ЧЗ, настроить УКЭПы в учетной системе.

19. Запустить процесс маркировки в эксплуатацию. Контролировать корректность проведения операций и передачи данных в "Честный знак".

20. Актуализировать задачи второго приоритета на доработку учетной системы. Выполнить доработки в соответствии с действующим в компании порядком ведения разработки программного обеспечения.

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

Часть 2. Спасение утопающих - дело рук самих утопающих

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

Не спасает ситуацию вариант массовой загрузки данных в ГИС МТ через csv-файл или xml-файл. Формат csv требует дополнительных действий пользователя: экранирование специальных символов, изменение настроек Windows, контроль разделителей и формата кодировки.

Вариант xml-файла, как способ перегрузки данных из учетной системы в ГИС МТ, не вызвал бы вопросов, если бы не формат вывода данных в ЛК Честный знак в виде строки. Например, документ Отгрузка в ЛК Честный знак предстанет перед грузоотправителем и грузополучателем в следующем виде.

Не существует в ЛК Честный знак и возможности экспортировать данные в файлы Excel или csv. Разве что выгрузка из Национального каталога отчета по карточкам товара, находящихся в статусе Опубликована.

Оптимальным вариантом взаимодействия с ГИС МТ является обмен данными через методы API. Для этого можно воспользоваться либо сторонними сервисами (Мой склад, Таском и т.д.), либо стандартными механизмами, встроенными в учетные системы, либо разработать функционал с нуля.

Часть 3. На 1С надейся, но сам не плошай

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

1. Различие в названиях объектов и реквизитов между 1С и ЛК Честный знак. Например, документ Ввод в оборот спрятан за названием Маркировка товаров ИС МП. В документации на сайте https://честныйзнак.рф используется сокращение ГИС МТ, а в 1С - ИС МП. Способ ввода в оборот Производство вне ЕАЭС в 1С называется Импорт и т.д.

2. В регистре сведений Очередь сообщений ИС МП скапливаются неотправленные запросы, исправление ситуации требует вмешательства разработчика.

3. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно получить актуальный статус кода маркировки или списка кодов маркировки. Статус кода можно увидеть непосредственно в ЛК Честный знак.

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

5.1С не запрашивает актуальный статус документов в ГИС МТ, поэтому в журналах присутствуют документы со статусом "ошибка", тогда как по факту в ЛК Честный знак пользователь видит статус обработан. Возможность изменить статус вручную не предусмотрена.

6. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно создать Заказ на эмиссию со способом ввода в оборот Перемаркировка. Как следствие пользователю необходимо выпустить коды маркировки непосредственно из ЛК Честный знак. Документ Перемаркировка, который вводит коды в оборот, не только не предусматривает возможности ввода в оборот без указания предыдущего кода, но и реализован с ошибками. Требуется тестирование функционала и доработки.

7. Если в настройках Интеграция с ИС МП включены две товарные категории Обувь и Товары легкой промышленности и одежды, то при загрузке из ГИС МТ документов Приемка, в реквизите Вид продукции система проставит Обувь, при этом нет возможности внести изменения вручную.

Поддерживать высокое техническое качество кода прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

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

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

Проблемы Алексея выглядели так:

• Бизнесу совершенно неинтересно, что находится под капотом и как сделать код лучше;

• Бизнес не разбирается в системе и не хочет это делать;

• Сам техлид не умеет вести переговоры;

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

Почему?! Потому что техлид говорил о каких-то технических вещах, а коллегам из бизнес-подразделений не интересно, как это работает. У них другие цели и задачи: как повысить конверсию, как привлечь больше людей, как сделать классный продукт. И технические детали им не интересны.

Из-за этого непонимания техлид не может продать идею. К тому же не все умеют уговаривать людей и просто продавать что бы то ни было. Недопонимание накапливается, и в итоге : Блин, да что с ними спорить? Я ему рассказываю, как надо сделать, а он ничего не понимает. Не буду этим заниматься в следующий раз!

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

Чем продажа идеи отличается от программирования?

Спойлер: ничем!

Есть три ключевые вещи, которые обязательно нужно сделать для того, чтобы успешно продать какую-то идею:

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

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

3. Использовать эмоции. С ними тоже нужно уметь работать. Но чтобы сделать это правильно, лучше пойти на какой-нибудь тренинг по эмоциональному интеллекту.

Пример неудачной продажи

Техлид приходит к владельцу продукта:

• Привет! Я хочу добавить в этот спринт задачу по рефакторингу.

• Привет! Нет, в этот спринт мы должны выпустить новую фичу, мы уже обещали.

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

• Ну, делайте сразу нормально, кто ж мешает?

Это результат неподготовленного диалога.

Давайте разберем ошибки типичного диалога техлида с бизнесом:

• Птичий язык: владельцу продукта непонятно, о чем мы говорим;

• Готовые решения. Человек, которому мы продаем идею, не участвовал в ее разработке. Он не знает, почему эта идея ему нужна и как она связана с тем, чего он хочет добиться;

• Потребность убедить в своей правоте, а не помочь решить проблему бизнеса.

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

Система продаж Джордана Белфорта

Есть замечательная цитата:

В фильме Волк с Уолл-стрит с Леонардо ДиКаприо прототипом главного персонажа является Джордан Белфорт один из самых известных продавцов и автор системы продаж.

На чем основывается его система? Джордан утверждает, что у вас купят идею (а на самом деле купят что угодно: телефон, автомобиль и т.д.), если есть 100% уверенность:

• В идее (продукте, предложении);

• В вас, как эксперте;

• В людях, которых вы представляете.

Рассмотрим бытовой пример: вам продают автомобиль.

• Идея 71%

Вы не совсем уверены, что автомобиль нужен вам как продукт. Но все же вам нужно ездить из пункта А в пункт В (на дачу, возить ребенка в школу).

• Эксперт 83%

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

• Команда 78%

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

Если во всех трех пунктах ваша уверенность 100% или близко, то скорее всего, автомобиль вы купите.

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

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

• Идея 0%

• Эксперт 100%

• Команда 100%

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

Если вы уверены, что автомобиль вам нужен, но при этом вы не доверяете продавцу вам кажется, что он хочет вас надуть или впарить 100500 опций, то конкретно у этого человека вы не купите:

• Идея 100%

• Эксперт 0%

• Команда 100%

В случае, когда вы не хотите связываться с АвтоВАЗом, и LADA Granta не ваша мечта, будет так:

• Идея 100%

• Эксперт 100%

• Команда 0%

То есть если даже один параметр будет не 100%, а 30-40% и ниже, вы не убедите человека купить автомобиль. А на месте техлида не продадите идею сделать тесты, что-то автоматизировать или провести рефакторинг.

Важный момент по поводу 100 баллов из 100. Вы можете только предполагать, каковы цифры на самом деле. Странно было бы на переговорах говорить человеку: А ну, скажи мне: от 0 до 100, насколько ты во мне уверен?. Это просто метафора, а не цифры, которые можно использовать в разговоре.

Как добиться уверенности на 100\100\100?

Идти по алгоритму.

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

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

Алгоритм продажи чего угодно, в том числе идей

Первые четыре секунды

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

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

Кратко изложите, зачем пришли (позвонили, назначили встречу). Человек, скорее всего, чем-то занят, это элементарная вежливость.

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

Раппорт

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

Отсутствие раппорта очень хорошо описывает картинка:

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

Сбор информации

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

Давайте посмотрим на три пункта:

• Боли ярко окрашенные негативные эмоции;

• Выгоды позитив;

• Цели и задачи более нейтральные вещи.

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

Основная презентация и предложение о покупке

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

Строим презентацию по схеме:

• Как ваша идея поможет собеседнику?

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

• Визуализируем ужасное будущее;

• Визуализируем хорошее будущее;

• Если это нужно, даем МИНИМУМ технических деталей;

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

• Называем цену.

Цена в кавычках, поскольку это может быть буквальная цена, или неделя работы. В любом случае (купить сервер и заплатить за это деньги или купить идею автоматизировать что-то и заплатить временем работы команды) алгоритмы продаж работают и во время договоренностей. Потому что любая договоренность, когда вы принесли какую-то идею, подразумевает действие и с обратной стороны. Человек в метафорическом смысле платит вам чем-то: своим вниманием, временем, тем, что ему придется выучить что-то новое. Не всегда речь идет о деньгах, но все-таки собеседник что-то дает вам взамен на вашу идею. Вы должны понимать цену этого.

Очень хорошая фраза, которая отдает мячик вашему собеседнику после презентации:

Мне кажется, это хорошая идея. Что скажешь?

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

Перенаправление на рост уверенности.

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

• Спросите, что смущает, и развейте страх

Если у вас не купили, значит, нет уверенности. Надо выяснить, где провал, почему 50% вместо 100%. И постараться это починить. Возможно, собеседник скажет напрямую:

• Я не уверен, что это поможет.

Об идее, скорее всего, можно говорить прямо. Но вряд ли человек скажет:

• Я тебе не доверяю, как специалисту.

Или:

• Мне кажется, твоя команда не справится.

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

Снижение порога действия

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

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

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

• Просто кивни, мы все сделаем сами.

• Тебе ничего не надо будет делать.

• Мы уже попробовали, и вот результат...

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

Усиление боли

Это визуализация страшного будущего, в котором ваш собеседник не согласился на вашу идею:

• Если ничего не поменяется, то...

• Знаешь ли ты, что будем, если мы этого не сделаем?

• Через год станет

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

Закрытие сделки

Это опять передача мяча собеседнику:

• Что дальше?

• Ну что, попробуем?

• Ты согласен, что...?

Это прямые вопросы, которые вы задаете собеседнику: Ну, как? Берем работу в следующий спринт? Ставим в план на следующий месяц?. Но эти вопросы часто просто забывают задать. Мы вроде бы обсудили идею и просто ждем, когда человек сам скажет: Ладно, давай. Я буду делать то-то и то-то.

Нет, пожалуйста, возьмите инициативу на себя и задайте вопрос: Ну как, работаем дальше?.

Пример

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

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

Диалог был примерно такой:

• Привет! Я хочу обсудить одну техническую задачу, которая может ускорить время разработки задач и починки ошибок. Есть 10 минут, чтобы обсудить сейчас?

• Давай.

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

Дальше идет презентация:

Смотри, сейчас у нас нет автотестов, и каждую фичу перед выпуском мы тестируем руками, ЭТО ДОЛГО. Я с ребятами УЖЕ ПОСЧИТАЛ, что если мы закроем 15% функционала тестами, то разработка каждой новой фичи УСКОРИТСЯ НА 2 ДНЯ. Благодаря этому мы сможем сделать на 10 фич больше до дедлайна. Мы все сделаем сами, надо просто взять в этот и следующий спринты задачи по разработке тестов. За этот месяц мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. А еще это поможет быстрее чинить баги.

Что мы здесь видим? Во-первых, в презентации были указаны конкретные цифры. 15% функционала, 2 дня и 10 фич.

Во-вторых, был минимум технических деталей, а конкретно одна: 15% функционала надо закрыть. Цифра на самом деле не важна это может быть и 10%. Владельцу продукта важнее, что разработка новой фичи ускорится, или что баги будут чиниться быстрее.

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

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

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

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

• Что скажешь?

Это пример, как можно по такому алгоритму проводить продажи идей.

Полезные фишки

Есть полезные фишки, которые помогут в любом диалоге:

• НО наоборот;

В предыдущем примере как раз используется эта фишка: мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. Обычно мы говорим: Я сделал что-то хорошее, НО будет вот это и вот это плохо. То есть сначала обговариваем позитивные моменты, а потом идут НО и неприятные вещи. Поменяйте их местами: если есть что-то неприятное, сначала расскажите о нем, а потом о хорошем: Сейчас сделаем на 20% меньше фич, НО потом мы будем эти фичи печь как пирожки.

• Потому что;

Если вы просто говорите: Так, дорогой мой бизнес, надо сделать рефакторинг и точка!, вам ответят: Да иди ты со своим рефакторингом! Почему? Вы не объясняете собеседнику причины. Людям гораздо легче согласиться с вами, когда они понимают, зачем вы это делаете. бъясните, зачем вы продаете идею (возвращаемся к целям и выгодам). Если вы пришли с идеей без объяснений, почему это важно сделать, то ваш собеседник почувствует себя обескураженным, не зная нужных ему деталей. Объясняя, вы выравниваете диалог.

• Визуализация;

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

• Двойная петля;

Если вы видите, что собеседник сомневается (сначала у него есть один аргумент против, потом появляется другой, третий), скажите ему прямо: Мне кажется, что ты не уверен в идее, которую я принес. Расскажи, почему?. Так он попадает в двойную петлю: либо говорит: Нет-нет, я уверен, и начинает сам себе продавать уверенность, либо говорит: Да, я не уверен, и тогда дает вам аргументы, с которыми вы сможете работать.

• Прямолинейность.

То, что вы честно и открыто ведете диалог, всегда подкупает.

Подводя итог

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

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

Кроме того, вы должны добиваться 100% уверенности по трем пунктам: в продукте, который продаете, в вас, как эксперте, и в людях, кого представляете.

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

TechLead Conf 2021 пройдет 30 июня 2021и 1 июля 2021 в московской Radisson Slavyanskaya. Расписание можно посмотреть здесь.

Билеты на конференцию вы можете приобрести уже сейчас. Спешите: 1 мая цена станет выше!

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

Производственные системы и их решения

Об одном из показательных примеров - о совместном решении Dassault Systemes и ГК Цифра - рассказал старший технический специалист компании Dassault Systemes Дмитрий Лопаткин. Группа компаний Цифра разрабатывает и внедряет платформенные решения на основе промышленного искусственного интеллекта и интернета вещей, а также развивает индустрию роботизированного промышленного транспорта.

"Допустим, обеспечена возможность подключения и сбора данных с промышленного оборудования и работы с этими данными. Какой необходимо сделать следующий шаг? спрашивает Дмитрий Лопаткин. ИТ - это всего лишь инструмент, который помогает решать задачи бизнеса, увеличивающий операционную эффективность.

Если говорить о программном продукте для оперативного управления производством компании Dassault Systemes - DELMIA Apriso и его архитектуре, то на его самом нижнем уровне лежит собственная, встроенная платформа управления бизнес-процессами Process Builder. И это единственный обязательный реквизит, необходимый для внедрения подобных систем. Именно здесь описываются все производственные процессы, входящие в контур цифровизации. Помимо самих процессов прописываются все интерфейсы подключения к оборудованию через системы автоматизации или непосредственно подключение бизнес-систем, таких как ERP. На эти бизнес-процессы наслаиваются функциональные модули, которые могут применяться на пользователями из различных производственных дисциплин: контроль качества, склады, ТОиР, декларация производства. Это те элементы, с которыми взаимодействует конечный пользователь оператор ЧПУ, плановик, сотрудники логистической или ремонтной службы и пр.".

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

Описание и моделирование бизнес-процессов

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

В ПО Process Builder бизнес-процессы описываются в графическом интерфейсе. Для каждой функциональной области используется набор стандартных бизнес-компонентов. В библиотечные каталожные компоненты в интерфейсе заносятся те значения, которые должны быть получены с оборудования они получаются автоматические или вводятся оператором вручную. Также описывается входная и выходная информация на каждом шаге процесса. Таким образом, описывается, как "живёт" предприятие, как оно функционирует.

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

Также можно моделировать, как себя будет вести процесс "в реальной жизни" - ещё до его запуска в производство. С точки зрения конечного пользователя эти изменения не видны, то есть, если в процесс внесены какие-то улучшения или усовершенствования в рамках BPM-платформы, то пользователь не увидит изменений, которые произошли в бизнес-процессах. Такая интеграция и возможность работы с процессами рамках инструмента Process Builder позволяет постоянно улучшать процессы, то есть можно сделать какое-то изменение, чтобы посмотреть, как это выглядит в реальной жизни, получить обратную связь от производства, оценить такие показатели как объем производства, выявить "узкие места" или внести изменения в процесс системы управления производством.

Ядро и интерфейсы пользователя

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

Ещё одно преимущество такого процессного подхода: с помощью BPM-платформы можно выделить наиболее эффективный для производства набор стандартных процессов и затем их масштабировать. Например, для распределенного производства - выделить процессное ядро (core), и быть уверенным в том, что любая производственная площадка, независимо от того, где она находится территориально, функционирует по стандартизированным и унифицированным бизнес-процессам.

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

Масштабирование системы

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

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

Что даёт такой подход с точки зрения информационных технологий? Во-первых, это высокая скорость внедрения. Обычно 60%-70% времени тратится на разработку основного решения (core), а дальнейшее внедрение требует уже незначительного времени. Например, на подключение новой производственной площадки уходит 2-3 недели, что по меркам систем управления производством очень малый срок.

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

Интеграция с "Цифрой"

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

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

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

Третья операция - операция сборки. У оператора на сборке своя задача и свои потребности: он хочет видеть весь процесс детально. Он проходит обязательный контроль соблюдения мер безопасности. Эта информация в рамках системы контроля качества сохраняется в системе управления производством Apriso. Каждый индивидуальный использованный материал и полуфабрикаты также заносятся в систему управления производством и добавляются в генеалогию изделия.

Рабочие инструкции, созданные ранее, на этапе технологической подготовки производства становятся доступны оператору на его персональном АРМ -непосредственно на рабочем месте и в различных форматах: чертежи, отсканированные pdf-файлы, или в виде 3D модели, как представлено ниже.

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

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

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

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

Преимущество такого решения в том, что оно позволяет собирать информацию c оборудования компании "Цифра". Есть система контроля процессов. Такой совместный подход дает большую синхронизированность работы всех производственных служб, увеличение эффективности использования оборудования и гибкости производства в целом. Всегда можно оперативно отреагировать на изменения, которые требует ситуация на рынке. Решение DELMIA Apriso обеспечивает глобальное управление процессами, контроль производительности, визуализацию и тщательный анализ влияния функциональных улучшений на всех производственных площадках в рамках предприятия.

Стоит отметить, что в одном из реализованных проектов внедрения системы управления производством Dassault Systemes ею пользуются 28 подключённых предприятий. Для реализации подобного проекта требуется от 9 месяцев. С учётом сложности процессов внедрения это очень хороший результат.

Заинтересовала данная тематика?

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

Познакомьтесь с материалом "Системы управления производством и производственными операциями и современные вызовы".

Узнайте больше о продуктах DELMIA на официальном сайте компании

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

Автоматизация бизнес-процессов

Развитие технологий разговорного ИИ (Conversational AI) достигло такого уровня, что сегодня виртуальных агентов в колл-центрах уже почти невозможно отличить от живого человека они способны точно имитировать различные интонации, делать паузы и адекватно распознавать намерения клиентов.

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

Онлайн-знакомства

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

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

Голосовые помощники

Кажется, голосовые ассистенты скоро будут у каждой уважающей себя IT-компании. Начиналось все c зарубежных Siri, Google Assistant, Alexa, затем появились Алиса от Яндекса, Олег от Тинькофф банка и Маруся от Mail.Ru Group. Некоторые помощники обретают физическую форму в виде колонки или станции, другие остаются только в виртуальном виде.

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

Подкастинг

Рынок подкастов продолжает уверенный рост. По данным недавнего исследования, к 2026 году его размер достигнет $41,8 млрд. Аудиоконтент востребован как никогда свои подкасты запускают крупные СМИ, IT-компании, банки, независимые эксперты и отдельные энтузиасты. Диапазон тематик широк: от развлекательных ток-шоу и обзоров новостей до образовательных и бизнес-программ.

Рекламодатели тоже не обошли индустрию подкастов стороной. Согласно прогнозам PwC, объем рекламного рынка подкастинга в России составит $133 млн к 2023 году.

Голосовая биометрия

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

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

***

А какие еще интересные и необычные голосовые инструменты и приложения знаете вы?

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

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

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

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

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

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

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

Аннотация

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

• начать что-то добывать;

• начать что-то производить;

• начать что-то перепродавать;

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

• захватить один из транзакционных каналов рыночного процесса.

Несколько тезисов

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

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

3. На основе ресурсной базы участников процесса формируется культура поведения.

4. Нечто, с помощью чего предприниматель вклинивается в существующие рыночные потоки, называется продуктом.

5. Прибыль извлекается с помощью бизнес-модели.

6. Возникающие денежные потоки дают предпринимателю (предприятию) возможность для развития.

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

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

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

Качество операций влияет на процессы, являясь узкими местами. Качество процессов влияет на качество уровней. А качество уровней в совокупности влияет на совокупные результаты и характеризует состояние компании на рынке.

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

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

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

Ссылка на карту в Miro: https://miro.com/app/board/o9J_kxviOm0=/

P.s. Этот материал изначально писался два года назад. На текущий момент фреймворк используют приличное количество менеджеров в приличном количестве довольно известных компаний в разных странах СНГ. Если он пригодится в вашей работе буду счастлив.

Всем доброго времени суток!

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

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

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

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

Ранее мы уже были в гостях у компании, затрагивали тему технологии беспроводной передачи данных на примере Wi-Fi 6 (IEEE 802.11ax). Нам также удалось не только провести экскурсию по производству, но и застать руководство врасплох вопросами о бэкдорах)

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

Погрузиться на практике в организацию бизнес-процессов и технологического конвейера разработки программных и аппаратно-программных решений мы решили с Артемом Олеговичем Вендерлых - руководителем департамента программной инженерии беспроводных решений предприятия Eltex. Для этого мы записали видеоконсилиум, а также совместно подготовили данную статью)

Кратко о бизнес-процессах

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

Основные этапы разработки и производства

Рассмотрим этапы разработки и производства более подробно. Предприятие активно взаимодействует с заказчиками и анализирует ключевые тренды рынка, что позволяет своевременно выпускать конкурентоспособную продукцию отечественного производства. Идея разработки нового устройства формализуется в виде технических требований при участии архитектора и сотрудников коммерческого отдела и сервисного центра. На этапе проработки требований первостепенная цель - конкретизировать ключевые особенности аппаратной и программных частей, а также согласовать дорожную карту развития продукта. На следующем этапе при участии лаборатории Hardware подбирается электронно-компонентная база (ЭКБ), удовлетворяющая поставленным задачам. В качестве примера можно привести выбор центрального процессора: его характеристики должны соответствовать ожидаемой производительности, целевой себестоимости и предельному энергопотреблению. Ключевыми артефактами данного этапа являются принципиальная и структурная схема устройства. На основе этих схем рисуется топология, после чего заказывается плата. Тут важную роль играет отдел снабжения, который взаимодействует с поставщиками ЭКБ и обеспечивает бесперебойную поставку компонентов для производства устройств.

Этап запуска первых опытных образцов устройства обычно называется Bring-Up и характеризуется взаимодействием отдела разработки и лаборатории HW. Для запуска устройства нужен софт - это зона ответственности отдела разработки. За основу софта берется SDK ключевых ЭКБ устройства и готовится первичный софт, именуемый прошивкой, для возможности проверки основных электронных компонентов, таких как: светодиоды, phy, wi-fi радиомодули.

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

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

Одновременно с этим команды разработки и сервисного центра активно работают над софтом для устройства. После чего устройство подходит к этапу массового производства и активных продаж. Жизненный цикл устройства составляет 3-5 лет, и на всём протяжении жизни обеспечивается техподдержка, а также модернизация устройств.

Софт формируется в релизы - это совокупность работ, которые нужно выполнить к определенному сроку. Для этого используется баг трекер, где фиксируются основные задачи. Разработка релиза делится на несколько этапов: планирование, разработка, стабилизация и выпуск релиза, включающий проверки в эксплуатации. На выходе получается прошивка, которая в дальнейшем используется на производстве для выпуска партий устройств. Рассмотрим, из чего состоит типовая прошивка. Роль основной системы устройства играет одна из версий Linux, модернизированное ядро которой обычно идет в составе SDK производителя основных ЭКБ. Для запуска системы используется загрузчик. На каждое устройство и версию ПО соответствующим отделом разрабатывается и обновляется исчерпывающая многоязычная документация. Вся рабочая документация хранится в системах организации и хранения знаний: Confluence, Wiki.

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

Используемый стек технологий

Разнообразные языки программирования и технологии позволяют предприятию решать широкий диапазон комплексных задач: от написания модуля ядра, разработки высоконагруженных сервисов, развертывания их в Docker с использованием Kubernetes до создания Android/IOS приложений.

Ресурсы аппаратного обеспечения сетевых устройств зачастую ограничены. Эта особенность определяет стек технологий для создания встроенного программного обеспечения. Соответственно, на предприятии Eltex используется язык Си, как основной язык ядра операционной системы Linux. Широко используется С++, в некоторых лабораториях есть опыт написания модулей на Rust. Для решения узких задач пишутся вставки на ассемблере. В одной из лабораторий для написания высокопроизводительный приложений для телефонии используется язык Erlang. Для отладки кода используются следующие инструменты: отладчики (GDB); средства захвата и анализа сетевого трафика (wireshark); утилиты отладки использования памяти и трассировки системных вызовов (valgrind, strace); статические анализаторы кода (cppcheck, PVS-studio). Для сборки прошивок разворачивается Jenkins, сборки осуществляются в Docker контейнерах.

Обеспечением качества и поддержкой продуктов в эксплуатации занимается отдельный отдел - сервисный центр. Их главная задача - обеспечить выпуск ПО, удовлетворяющего внутренним критериям качества. Они пишут тесты различного назначения (функциональные, интеграционные) на bash и python. Создают инфраструктуру, обеспечивающую поддержку постоянного уровня качества. На каждом из этапов команда взаимодействует с разработчиками, обеспечивая контроль качества выпускаемого ПО: прорабатываются и выполняются тесты как по отдельным задачам, так и по крупным фичам, разрабатываются стенды и схемы интеграционных проверок, модернизируются старые и пишутся новые тесты. Регулярные автоматические тесты позволяют выявить ошибки на раннем этапе. В зависимости от направления и тестируемого продукта используются различные инструменты. Для автоматизации тестов задействуются следующие инструменты: pytest, selenoid, allure, яндекс танк, ansible. Используемые инструменты для логирования: graylog, elasticsearch, influxdb, telegraf, prometheus, grafana. Также стоит отметить, что для организации ci-cd применяется gitlab.

Невозможно представить сетевые устройства без сервисов управления и мониторинга. ПО данного типа может быть как в составе железа (WEB-интерфейс), так и распространяться в виде deb-пакетов или Docker контейнеров (контроллерные решения). Для внешних решений используются языки java, kotlin, go, python. При разработке встроенного WEB-интерфейса используются Angular/JS для фронтенда и lua/C++ для бэкенда.

В компании есть группа, которая пишет Andoid/Ios приложения для мобильных устройств на Java и Swift. Эта группа разрабатывает различные вспомогательные приложения для Media приставок, а также для проекта умного дома/офиса.

Заключение

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

Безусловно, без внимания остались и другие не менее интересные вопросы. Но не все сразу!) Подробнее с темой Вы можете ознакомиться в видеоконсилиуме.

Надеемся, материал был интересен и полезен. Если подобный формат понравится студентам и сообществу Хабра, то постараемся и дальше записывать интересные консилиумы.

Приветствую, Хабр!

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

Проблемы традиционного взгляда на бизнес-процессы

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

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

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

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

И здесь встаёт вопрос: если среда неумолимо меняется и воздействует на нас, зачем выстраивать жесткую систему менеджмента и отливать в монолите бизнес-процессы? С точки зрения контроля над компанией и минимизации операционных рисков всё понятно. Но, на мой взгляд, избыточно структурированные системы имеют риск разрушения, как только столкнутся с непредсказуемостью.

Гибкое управление бизнес-процессами

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

Я представляю процессы НЕ как что-то искусственное, в стиле: "вот мы описали процессы и они начали существовать", а как органическое следствие роста организации, где с каждым шагом по рынку появляются всё новые проблемы и задачи, направленные на их решение. А на основе опыта решения проблем в компаниях появляются "Тропинки действий", которые мы и называем бизнес-процессами.

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

Есть такой термин как Adaptive Case Management. Его еще называют Agile BPM. Суть метода как раз описывает внедрение изменений в задачи на основе полученного опыта, где кейсы это ситуации, с которыми компания сталкивались в прошлом. Если проблема была решена успешно, то оставляем последовательность задач как было. Если проблема была решена плохо, то вносим коррективы и в следующий раз используем другой алгоритм.

Информационные системы и гибкое управление процессами

Когда нарастание сложности компании превращается в корпоративный хаос, менеджеры задумываются о внедрении инструментов, чтобы удержать контроль над системой. И здесь на помощь руководителям призваны различные информационные системы. Причём не важно, идет ли речь об ERP, BI, BPM, CRM, обычные таблицы любой класс этих продуктов для большинства менеджеров разновидность учёта и контроля качества бизнес-процессов. Где-то менеджеры контролируют движение денежных потоков. Где-то контролируют входящий клиентский поток. Где-то контролируют работ, которые выполняют сотрудники.

В гибком управлении процессами информационная система в большей степени не инструмент учёта управленца, а прежде всего инструмент для удобного взаимодействия сотрудников, где они могут сами организовать планирование и учёт в том виде, в котором это удобно для выполнения работы. Это когда-то давно поняли японцы, создавшие для координации и управления целыми заводами простые канбан доски. Сегодня это понимают разработчики таких инструментов как Trello, Airtable, Miro, Notion, Slack, Unicore и других сервисов...на первый взгляд, между этими системами мало чего общего. Но, по-моему, все они решают одну большую проблему предприятий отсутствие общего, удобного и адаптируемого информационного пространства для совместного решения задач бизнеса.

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

Относительно недавно появился термин Work Management System то, о чём я пишу об этом. Софт становится человекоориентированным и гибким, чтобы с помощью него не менеджеры управляли процессами, а сами сотрудники.

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

Дебиторская задолженность (далее встатье ДЗ) это долги юрлиц ифизлиц предприятию. Чем быстрее можно добиться ихпогашения, тем она более ликвидна.

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

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

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

Размер задолженности также должен быть оптимальным. Нулевая или небольшая задолженность говорит отом, что деньги просто лежат набалансе. Большой размер долгов дебиторов при недостатке денежных средств насчетах создает трудности вфункционировании предприятия: нечем платить сотрудникам ипоставщикам.

Как образуется задолженность

Вариантов возникновения много, приводим самые распространенные.

Состороны контрагентов:

• когда компания платит аванс поставщику или подрядчику;

• когда покупатель (вего роли может выступать филиал или дочерняя организация) сначала получает товар или услугу, аплатит потом;

• когда контрагент наносит ущерб компании икомпенсирует его несразу (например, если логистическая компания повреждает товары при транспортировке).

Состороны госструктур:

• при переплате налога;

• при вычете входного НДС (приобретая товары вцелях осуществления операций, облагаемых НДС, налогоплательщик имеет право навычет (ст.171 и172НК РФ));

• при социальных выплатах, которые возмещает ФСС (например, когда сумма выплаченных сотруднику пособий превысила страховые взносы или когда покрываются расходы напредупредительные меры (до20% сумм взносов запредыдущий год можно потратить наних)).

Состороны сотрудников иучастников предприятия:

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

• когда работодатель выдает сотруднику заем;

• когда участник общества задерживает платеж вуставный капитал.

Как посчитать ликвидность

Ликвидность ДЗможно оценить спомощью коэффициента ееоборачиваемости или спомощью периода ееоборота.

1. Коэффициент считают как отношение выручки кдебиторке запериод времени:

Коб.дз = ДР/ ДЗср,

где:

• Коб.дз коэффициент оборачиваемости Д;

• ДР доход компании отреализации продуктов или услуг запериод времени (обычно загод, квартал или месяц);

• ДЗср средняя дебиторская задолженность заэтотже период, т.е. суммаДЗ наначало иконец периода/2.

Тоесть расчет побалансу будет выглядеть так:

Коб.дз = 2110/ (1230на начало периода 1230на конец периода) х0,5

2. Период оборота равенДЗ наконец периода, умноженной наколичество дней расчетного периода иделенной надоход:

Поб.дз = ДЗкп хП/ ДР,

где:

• ДЗкп задолженность наконец периода;

• П период, выраженный вколичестве дней;

• ДР доход компании отреализации продуктов или услуг заэтоже период.

Тоесть расчет побалансу будет выглядеть так:

Поб.дз = 1230на конец периода хП/ 2110

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

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

Оценка качества задолженности

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

Поотношению ксроку погашения:

• Срочная или нормальная (срок погашения еще ненаступил).

• Просроченная, может также подразделяться накатегории подлительности просрочки вднях. Например: до30, от31до60, от61до90, более 90.

Более мелкое деление помогает оценить риски невозврата: чем дольше дебитор задерживает оплату, тем меньше шансов, что онпогасит долг. Срок исковой давности повзысканию просроченной задолженности ограничен, составляет три года (ст. 196ГК РФ). Отсчет начинается сдаты, когда организация узнала онеуплате (например, день, следующий заднем платежа подоговору.

Если задолженность регулируется договором, вкотором неуказан срок возврата, тосрок давности надо начинать отсчитывать через 30дней после предъявления требования вернуть долг, ипри этом оннедолжен быть больше 10лет смомента возникновения долга (п. 2ст. 200ГК РФ).

Повероятности возврата:

• Надежная: непросроченная либо подтвержденная надежным контрагентом или обеспеченная гарантией.

• Сомнительная: та, которую могут непогасить вообще или вполном размере. Обычно это просроченная инеобеспеченная залогом, поручительством или банковской гарантией (п. 1ст. 266НК РФ), нодаже если компания изкаких-либо источников узнает офинансовых трудностях контрагента, его долг тоже стоит считать сомнительным. Поистечении срока взыскания становится безнадежной.

• Безнадежная: та, которую нельзя взыскать. Может быть просроченной систекшим сроком исковой давности, или признанной таковой порешению суда (например, при банкротстве дебитора, когда оставшиеся средства достались кредиторам предыдущей очереди), или относиться корганизации, которая уже ликвидирована (п. 2ст. 266НК РФ). Исключение для третьего случая долгИП: ондаже после исключения изреестра отвечает пообязательствам своим имуществом (ст. 24ГК РФ), если суд непризнал его банкротом.

Повеличине срока погашения:

• Краткосрочная или текущая (вбалансе относится кбыстро реализуемым активам, группаА2): погашение планируется втечение года (можно также отдельно выделить долги, которые будут оплачены втечение квартала имесяца).

• Долгосрочная (вбалансе относится кмедленно реализуемым активам, группаА3): погашение ожидается более чем через 12месяцев. Когда срок возврата долгосрочного долга становится меньше, чем 1год, онпереходит вкатегорию краткосрочных.

Степень ликвидности также можно оценить нетолько поформуле, ноиспомощью ручной группировки:

• ДЗсосроком погашения до30дней высоколиквидная.

• Безнадежная неликвидная.

• Остальная среднеликвидная.

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

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

Как анализировать

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

Например, сравнивать:

• размерДЗ собщим объемом текущих активов;

• темпы ростаДЗ стемпами роста дохода;

• размер исрок оборачиваемостиДЗ саналогичными параметрами кредиторской задолженности;

• фактическую оборачиваемостьДЗ сожидаемой (согласно договорам).

Так рост дебиторки должен быть связан сростом сбыта икоррелировать сростом кредиторской задолженности. Чтобы невозникало кассовых разрывов, ликвидность иобъемДЗ должны быть сопоставимы сликвидностью иобъемомКЗ, иобъем дебиторки также недолжен быть занимать слишком большую долю втекущих активах.

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

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

Как повысить качество иликвидность

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

Действовать можно понескольким фронтам:

• Предупреждать риски (детальная проработка договоров, условий сотрудничества).

• Контролировать взаиморасчеты, оплаты, добиваться проведения просроченных платежей.

• Анализировать результаты.

• Корректировать кредитную политику.

Как можно работать срисками

1.Прописать вдоговоре

• неустойки (штрафы, пени), возможность удержания имущества должника идругие карательные меры вслучае неуплаты;

• особые условия перехода права собственности напродукт: переход только вмомент оплаты (чтобы при банкротстве контрагента можно было вернуть неоплаченное имсвое имущество);

• правила корректировки условий сотрудничества (цен/ гарантийных сроков/ сроков отсрочки платежей ит.п.) вслучае изменения условий рынка;

• возможность расторжения договора водностороннем порядке вслучае неисполнения второй стороной условий этого договора;

2. Создать резервный фонд насумму сомнительных долгов;

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

• Если возможно, брать сконтрагентов депозиты.

Как получать платежи всрок ивозвращать сомнительные долги

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

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

• Ежемесячно сверять взаиморасчеты.

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

• Регулярно требовать провести просроченные платежи.

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

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

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

1. Регулярно анализируйте иранжируйте дебиторов (можно методом ABC-анализа), работайте сдолговыми реестрами, ищите причины появления просрочек, признаки добросовестных инедобросовестных контрагентов.

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

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

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

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

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

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

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

Ключевой особенностью процессного управления является совершенствование основных видов деятельности, повышение качества выходов и квалификации сотрудников. Циклы непрерывного совершенствования, изложенные Эдвардсом Демингом (PDCA) или к концепции six sigma (DMAIC) должны быть реализованы в компании, которая внедряет процессное управления.

Как внедрять процессное управление у себя в компании? Для того, чтобы внедрить процессное управления необходимо ПОСЛЕДОВАТЕЛЬНО пройти четыре основных этапа: бессистемный, системный, измеряемый и совершенствуемый. Давайте рассмотрим характерискики каждого из этапов.

Бессистемный этап это начало пути по внедрению процессной методологии управления. Данный этап характеризуется тем, что вы не рассматриваете работу компании как систему взаимодействующих и/или взаимосвязанных процессов. На этом этапе проект инициируется и планируется. Главной отличительной особенностью данного этапа является создание в компании атмосферы безотлагательности изменений. Далее определяется внутренний заказчик, формируется команда реформаторов и пропагандируется необходимость изменения сотрудникам. Желательно оформить ваше видение проекта на бумаге, то есть, сформировать базовый календарный план внедрения, определить заинтересованные стороны, каналы внутренней коммуникации, отчетность, человеческие и финансовые ресурсы и, разумеется, конечный результат проекта. Необходимо, чтобы все понимали что мы делаем, куда мы движемся и что нас ждет.

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

Классификация бизнес-процессов:

• Процессы управления.

• Основные процессы.

• Обеспечивающие (вспомогательные) процессы.

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

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

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

Итак, переходим к следующему этапу жизненного цикла процессного подхода измеряемому. Для того, чтобы предпринимать шаги по совершенствованию своей операционной деятельности необходимо осуществить анализ и измерение текущей ситуации. Измерение бизнес-процессов осуществляется с использованием ключевых показателей эффективности (КПЭ или KPI). При формировании КПЭ процессов необходимо руководствоваться следующими правилами: как процесс влияет на конечный результат, ценный для потребителя? и как процесс влияет на прибыль компании?. К характеристикам КПЭ бизнес-процессов можно отнести:

• Минимально возможное количество.

• Измеримость.

• Контролируемость.

• Улучшаемость.

На совершенствуемом этапе, когда вы знаете как работает ваша система процессов компании, когда вы провели измерения и выявили уязвимые, не устраивающие вас участки процессов, пора приступать к мероприятиям по оптимизации бизнес-процессов. Для этого необходимо четко сформулировать видение развития компании (стратегия развития, система сбалансированных показателей и т.д.) и донести ее до сотрудников. Также основными инструментами по оптимизации бизнес-процессов выступают: цикл Деминга (цикл PDCA Plan-Do-Check-Act) или методология DMAIC (Define-Measure-Analyze-Improve-Control). Цикл PDCA представляет собой алгоритм последовательности действий, необходимых для повышения качества бизнес-процесса: планирование, реализация, контроль и реагирование (корректировка). Методология DMAIC основана на цикле Деминга и представляет собой алгоритм с более расширенной последовательностью действий, нежели PDCA: определение, измерение, анализ, совершенствование и контроль.

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

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

• Стандартизация работы процесса (сокращение ошибок в работе сотрудников).

• Контроль выполнения эффективности операций.

• Обучение сотрудников.

• Анализ и совершенствование бизнес-процессов.

• Внутренний аудит компании.

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

BPMN предназначен, прежде всего, для описания моделей процессов на предприятии. Для описания моделей обмена данными на предприятии А также для генерации кода в формате XLM для BPMS систем.

BPMN помогает в решении следующих задач:

• Реорганизация работы коллектива

• Автоматизация деятельности сотрудников

• Автоматизация деятельности сотрудников в BPMS

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

Это позволяет:

• оптимизировать рабочий процесс,

• улучшить взаимодействие между подразделениями,

• повысить результативность.

Автоматизация деятельности сотрудников помогает в создании технического задания для программистов. Если мы говорим об автоматизации в BPMS, подразумевается, что BPMN позволяет создавать исполняемые графические нотации.

Для реорганизации создаются две модели:

AS IS - Как было. Эта модель описывает текущую ситуацию в работе компании.

TO BE Как должно быть.

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

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

Данное видео является частью "Базового видео-курса по BPMN"

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

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

В видео применение рассматривается на примере трех сценариев.

Данное видео является частью "Базового видео-курса по BPMN"

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

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

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

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

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

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

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

К преимуществам функциональной модели управления можно отнести:

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

• Быстрая обучаемость новых сотрудников или повышение квалификации.

• Быстрая постановка задач директором для функциональных подразделений (время их выполнения это уже другой вопрос).

К недостаткам относятся:

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

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

• Несогласованность действий и возникновение конфликтов, что в итоге приводит к увеличение сроков реализации готового продукта.

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

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

• Отсутствие измеримых показателей (KPI), оценивающих влияние подразделений и сотрудников на конечный результат.

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

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

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

Рабочий процесс осуществляется согласно утвержденному регламенту, в котором задействованы кросс-функциональные команды участников бизнес-процесса из разных подразделений. Владелец процесса осуществляет мониторинг реализации деятельности сотрудников посредством специальных индикаторов ключевых показателей эффективности бизнес-процесса. Роль руководителя заключается в контроле операционной эффективности (10-20% рабочего времени), а также разработки стратегии развития и формирования предложений по оптимизации подконтрольного бизнес-процесса (80-90% рабочего времени).

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

К преимуществам процессной модели можно отнести:

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

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

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

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

• Повышение операционной эффективности компании.

• Быстрое обучение новых сотрудников (регламенты, инструкции и т.д.).

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

• Отсутствие длительных процедур согласования.

• Отсутствие конфликтов среди топ-менеджмента (все играют по правилам).

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

Дорогие друзья, если вам интересно узнать о внедрении и сопровождении процессного управления, то прошу написать в комментарии. В этом случае я продолжу писать. Заранее благодарен!)