Автоматизация предприятий

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

Пару слов о себе, и почему я вообще решил написать об этом. Мои рабочие обязанности заключаются, в том числе, в том, чтобы заставить любой имеющийся в компании станок с ЧПУ делать всё, что он вообще может физически. Компания небольшая (единицы сотен сотрудников), но в арсенале вертикальные фрезерные автоматы Haas трех разных поколений, горизонтальные фрезерные автоматы DMG Mori нескольких типов, лазерный резак Mitsubishi, токарные автоматы Citizen Cincom и куча всего еще. И весь этот зоопарк управляется программами на G-code. Изучая разные реализации этого языка, я понял, что то, что пишут в учебниках и книгах по нему не всегда является правдой. В то же время, мне стали понятны многие аналогии между этим языком и Assembler-ом, который я изучал когда-то в институте, и на котором практически ничего серьезного никогда не написал.

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

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

Базовый синтаксис

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

Традиционно, когда описывают синтаксис G-code, говорят, что любая команда в программе начинается с буквы G для подготовительных кодов и M для дополнительных, что номер строки начинается с буквы N, а номер программы или подпрограммы с буквы O. Это, в принципе, правда, но не вся и не всегда.

Во-первых, деление на G- и M-коды условно. Раньше, во времена первых станков с ЧПУ, это имело практическое значение, потому что связь синтаксиса с аппаратной реализацией была жестче. Сейчас же, это деление практически потеряло свое значение. Однако, правило о том, что M-код может быть только один на строке, все же стоит выполнять, как в старые времена, потому что никогда не знаешь точно, на сколько вольно производитель контроллера станка обошелся с реализацией языка. Например, на станках DMG Mori, автоматическое измерение длины инструмента, установленного в шпинделе, выполняется кодом G324, но если вы просто хотите активировать измерительный сенсор для того, чтобы почистить его (при этом крышка, под которой он скрыт во время обычной работы, открывается, и он выдвигается, но измерение не происходит), вам нужно выполнить код M44. По классической логике языка, использование G-кода для измерения длины нестандартное решение, потому что вы явно не хотите, чтобы одновременно с этим (одной строкой кода) выполнялись какие-то еще действия. Но в современных реалиях это не имеет значения. На станках Haas та же операция измерения делается вообще запуском специальной подпрограммы с параметрами (тип и номер инструмента), а не одним кодом. Плюс, практически любой контроллер позволяет определять пользовательские G- или M-коды, полностью стирая различие между ними.

Ветвление и циклы

В G-code есть условный и безусловный переход по команде GOTO. Синтаксис адреса (аргумента) этой команды может различаться. Чаще всего, это число, соответствующее номеру строки, заданному на самой строке, как Nчисло. Но некоторые реализации языка, например синтаксис контроллеров Okuma, позволяют давать строкам буквенные метки. С одной стороны, это хорошо, а с другой нетипично, что смущает некоторых программистов и операторов.

Условный переход выполняется традиционным IF [выражение] THEN команда. Конструкция ELSE в языке не нужна, потому что если условие ложно, команда на этой строке не будет выполнена, а будет выполнен переход на следующую строку. Это важно понимать, потому что ошибка с тем, чтобы поместить команду, которая должна быть выполнена только если условие истинно, на следующую строку одна из самых распространенных в ручном программировании. Вероятно, это случается с неопытными программистами, которые до этого привыкли к синтаксису языков высокого уровня. В некоторых реализациях не обязательно и THEN, что добавляет краткости, но не добавляет читаемости. Сравните (даже не имея представления о смысле):
IF [#1 NE 10] THEN #2=20
и
IF [#1 NE 10] #2=20

Циклы в явном виде реализованы конструкцией WHILE [выражение] DOметка ... ENDметка, но, конечно, могут быть реализованы и через условный переход. Синтаксис позволяет также выпрыгивать изнутри цикла, используя GOTO. Но запрыгнуть внутрь цикла, используя размещенную внутри него метку нельзя. Возможно, в каких-то контроллерах это и разрешено, но в тех, на которых я это проверял, это вызывает ошибку.

Подпрограммы

История использования подпрограмм в G-code тянется еще со времен перфолент. Существует несколько способов их вызывать, и это достаточно избыточно. Каждая программа или подпрограмма на G-code имеет свой идентификатор цифровой код. Положение (под)программы определяет, должен ли этот идентификатор начинаться с латинской O или латинской N. По этому коду их можно вызывать разными способами. Эти способы (используемые для этого коды) различаются, например, тем, где контроллер будет искать эту подпрограмму внутри файла (на станках Haas это код M97) программы или во всех файлах (а это уже M98). Если подпрограмма содержится в файле программы и имеет идентификатор номера строки (N), ее следует вызывать, как внутреннюю подпрограмму. В этом случае, совершенно не нужно беспокоиться об уникальности идентификатора. Если же подпрограмма имеет идентификатор, начинающийся с буквы O, она может содержаться и внутри файла основной программы, и в отдельном файле. В этом случае, следует заботиться о том, чтобы номер был уникален среди всех программ в памяти контроллера, потому что иначе, контроллер либо выдаст ошибку при попытке записать такую подпрограмму в его память, либо, что хуже, может выполнить первую попавшуюся подпрограмму из нескольких с одинаковыми номерами. На большинстве контроллеров это, к счастью, невозможно. В общем, любую программу можно вызвать, как подпрограмму, только из-за отсутствия кода возврата M99, аналога return, и присутствия кода остановки M30, аналога halt, контроллер просто остановит выполнение. Но в некоторых случаях (когда это действительно конец процесса обработки детали) это может быть совершенно нормальным решением, пусть оно и выглядит некрасиво с точки зрения классического программирования. Это различие, на самом деле, восходит к временам, когда носителем для программ были перфокарты и перфолента, которые нужно было менять вручную, если подпрограмма находилась на другой ленте или в другой пачке перфокарт.

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

Указатели, переменные, регистры

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

Если вы хоть раз видели программу на G-code для промышленного станка, вы, возможно, заметили, что в начале самой программы, а иногда в начале каждого фрагмента или подпрограммы, отвечающей за один инструмент или один элемент детали, есть длинная строка кодов, которые вроде бы ничего не делают. Это так называемая safe line. Она нужна, потому что станок помнит свое состояние. Например, содержимое какого-то регистра может сохраняться даже после выключения и включения станка, потому абсолютно всегда имеет смысл в явном виде устанавливать желаемое состояние перед совершением каких-то операций. Это напоминает то, как в web-разработке используются Reset.css и Normalize.css. Иначе, это правило для программистов звучит как никогда не предполагай, что станок находится в определенном состоянии, если ты его в это состояние не привел. Пренебрежение этим может стоить дорого, включая капитальный ремонт станка. При этом, наиболее надежной практикой считается именно приведение станка в искомое состояние, а не проверка, находится ли он в нем. Почему? Потому что приведение, как правило, делается одной безусловной командой, а проверка требует условного ветвления.

Практический пример. При использовании контроллера Haas, некоторые адреса доступны для чтения только по номеру ячейки памяти, тогда как для записи по буквенному псевдониму и по номеру. Скажем, чтобы установить скорость вращения шпинделя, достаточно выполнить код S<целое число>, запись IF [S EQ 200] (проверка если скорость шпинделя равна 200) работать не будет, нужно писать IF [#цифровой номер ячейки EQ 200]. Очевидно, что установить нужную скорость куда проще, чем проверить ее. Более того, я с большим трудом могу себе представить ситуацию, когда проверка была бы действительно нужна, за исключением всего одного случая, с которым мне пришлось столкнуться. Некоторые станки имеют в своем наборе инструментов вентилятор, который устанавливается в шпиндель, как обычный держатель фрез. Это нужно, чтобы сдувать охлаждающую жидкость и стружку с детали после окончания ее обработки. Работа вентилятора зависит от скорости вращения он складной, ему нужна определенная скорость, чтобы раскрыться от центробежной силы. Но станок имеет функцию изменения скорости вращения шпинделя, чтобы при отладке программы оператор мог на ходу переопределить скорость, заданную программой. Однако, если забыть отключить это изменение, вентилятор может или не раскрыться, или разлететься от слишком быстрого вращения. До того, как я начал работать в компании, этот вопрос никак не решался, считалось, что это ответственность оператора. Я же обратил на это внимание после первого происшествия и написал дополнение к программе для вентилятора, которое запускает вентилятор сразу после его установки в шпиндель, затем читает по нумерованному адресу (на счастье, документированному) значение реальной скорости вращения, делит его на устанавливаемую программой скорость и определяет, не различаются ли они больше чем на 1% (легкие вариации допускаются, хотя 1% это порог с запасом), и если различаются останавливает программу, включая индикатор ошибки и выдавая сообщение о том, что переопределение скорости следует отключить. Иронично, что тот же самый контроллер позволяет запретить переопределение некоторых параметров из программы (скорости движения стола, например), но не скорости вращения шпинделя. Почему? Так решил производитель. А моя задача сделать так, как нужно производству, несмотря на то, что думает производитель, не нарушая гарантию. Для типичного производственного программиста, который не связан с автоматизацией, подобное решение выходит за рамки его деятельности.

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

Приведение типов

Это одна из неприятных особенностей многих реализаций G-code и контроллеров. Глядя на параметр X10, логично предположить, что это целое число. Но, в зависимости от того, как контроллер работает и как настроен, машина может интерпретировать и как X10.0 и как X0.0010 в втором случае, это будет десять минимальных единиц инкремента для данного контроллера. (Что, в свою очередь, может быть и десять микрон и десять десятитысячных долей дюйма.) Чудовищно, правда? Студенты и начинающие операторы постоянно делают эту ошибку. При этом, это можно настроить в контроллере. Потому, для полной переносимости и независимости от настроек, десятичная точка должна быть в цифровых значениях координат абсолютно всегда.

Хуже становится, когда речь о параметрах, передаваемых вызываемой подпрограмме. Практический пример. Автоматический измеритель длины инструмента Renishaw, установленный на станке Haas, требует для запуска измерения одного инструмента код G65 P9023 A12. T1, где T1 номер инструмента (1, в данном случае). Но если вы хотите измерить сразу несколько инструментов, код будет G65 P9023 A22. I1. J2. K3. Тут уже параметры должны быть с точкой. Почему? Потому что когда вы пишете в T, этот адрес предназначен для хранения номера инструмента, потому на станке Haas он автоматически интерпретируется как целое число (мне неизвестны реализации, где это может быть дробное число, но я не могу этого исключить, например у одного инструмента могут быть разные режущие кромки, нумеруемые, как дробная часть его номера). А вот когда параметры передаются через регистры, хранящие локальный стек переменных общего назначения, точка нужа, потому что там может храниться что угодно. При этом, у тех же станков Haas есть две настройки, которые отвечают за изменение этого поведения. Одна касается ввода параметров в контроллер, а другая интерпретации некоторых именованных регистров использующихся для хранения координат.

Об обучении

Программированию станков с ЧПУ учат очень разными путями и с разными задачами. В одном случае, речь просто о том, чтобы научить пользоваться CAD/CAM, чтобы программист был в состоянии превратить модель (чертёж) в код, исполняемый на том или ином станке, изготавливающий деталь по модели. Это напоминает процесс обучения программированию общего назначения в ВУЗе, где вопросы исполнения кода, аппаратной архитектуры и написания кода на Ассемблере рассматриваются очень поверхностно. В других, заметно более редких случаях, процесс более всего напоминает обучение системному программированию, а примеры исполнения кода на конкретной архитектуре входят в него, как неотъемлемая часть. Поскольку я когда-то учился цифровой электронике, и программирование железа на низком уровне было частью этого, пусть и в довольно скромном объеме, второй вариант лично мне как-то ближе, и именно так я старался преподавать это сам, когда у меня была такая возможность.

Я вполне допускаю, что некоторые аналогии в статье могут показаться кому-то натянутыми, но я и не претендую на их точность. Речь, скорее, о сходстве духа упомянутых выше языков, о том, что опыт ассемблерного мышления может довольно сильно способствовать глубокому пониманию G-code, тогда как опыт программирования только на языках высокого уровня, отделенных от аппаратной реализации, может вызвать недоумение и даже некоторую неприязнь у того, у кого вдруг возникнет необходимость писать вручную для станков с ЧПУ.

Проектирование автоматизированной системы работы с дилерами

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

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

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

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

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

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

• Что будет в личном кабинете дилера?
• Просто заказы с документами и создание нового.

• Действительно, просто. А откуда возьмутся заказы? Как сейчас они создаются? Возможно ли взаимодействие с этой системой через api? Кто сможет их создавать в нашей системе? А кто не сможет? Можно ли отменить? А если заказ уже отгружен? У кого будет доступ к заказу? А документы в какой момент и откуда возьмутся? А можно ли их выгрузить? Как будут меняться статусы? Будет ли кто-то контролировать выполнение заказа? С заказом могут быть рекламные материалы, говорите? А что за материалы, кто их создает, кто прикрепляет к заказу?

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

Исследование

Исследование предметной области

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

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

Интервью с заинтересованными лицами, постановка бизнес-целей

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



Такие проблемы нам были озвучены:

• Вся работа с дилерами ведется по телефону и электронной почте. Заказ оформляется письмом на электронный адрес, обновления по нему обсуждаются в личном общении. Общение и оформление заказа ручной труд, который отнимает много времени сотрудников.
• Нет актуальной информации о наличии товара на складе. Информация об остатках поступает менеджерам утром и не обновляется в течение дня. При формировании заказа нельзя точно сказать, доступно ли нужное количество товара.
• У компании нет данных о деятельности дилеров: количестве товара на их складе, доле продукции компании в общем портфеле, популярности конкретных линеек товара, конечных покупателях и потребителях. Таким образом, нет возможности оптимально планировать отгрузки и маркетинговую деятельность.
• Дилеры не получают полную информацию о сотрудничестве с компанией, теряют документы, не понимают, насколько выполнен план продаж, не знают о положенных им бонусах и подарках.
• Анализ объемов продаж дилерам, остатки на их складах, планирование производства происходит в ручном виде аналитиком предприятия на основе догадок и предположений. Все данные собираются в один файл в формате excel, из него создаются отчеты.
• Руководители отдела не получают точной информации о работе сотрудников своего отдела и не могут точно планировать их загрузку, ставить планы продаж.

Таким образом, целями работы стали:

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

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

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

На первой встрече с нашим заказчиком мы также:

1. Узнали, что:

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

2. Получили:

• Договор партнерства,
• Пример аналитического отчета об отгрузках,
• Каталог продукции,
• Рекламные материалы.

3. Познакомились с:

• Генеральным директором,
• Коммерческим директором,
• Руководителем отдела продаж,
• Руководителем отдела маркетинга.,
• Руководителем отдела логистики,
• Главным бухгалтером.

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

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

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

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

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

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

Пример списка сотрудников для общения:

• Генеральный директор;
• Заместители директора (два человека);
• Руководитель дивизиона (три человека);
• Менеджер отдела продаж (три человека);
• Руководитель отдела логистики;
• Руководитель отдела маркетинга;
• Главный бухгалтер;
• Трейд-маркетолог;
• Аналитик;
• Дилер (три человека).

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

Пример описания текущей ситуации:

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

Для размещения заказа дилер отправляет письмо-заявку на электронный адрес закрепленного за компанией менеджера. В заявке он указывает:

1. Названия и количество товаров, которые необходимы,
2. Свои реквизиты;
3. Адрес грузополучателя, куда необходимо отгрузить товар;
4. Транспорт, которым необходимо отправить товар;
5. Желаемую дату отгрузки.

Менеджер отдела продаж создает новый заказ для дилера в системе 1С:

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

После размещения заказа для него формируется заявка на транспорт, которая отправляется в отдел логистики.

Пример пользовательских требований к новой системе:

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

На этом этапе аналитику важно содействие со стороны заказчика:

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



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

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

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

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

Полевые исследования

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



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

Технические особенности

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

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

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

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

В результате этапа исследования у нас, как правило, есть:

1. Сформулированные руководством цели и задачи для создания личных кабинетов;

2. Общее понимание и детальное описание бизнес-процессов, которые будут автоматизированы в результате их создания;

3. Список пользовательских требований от каждого типа пользователей личного кабинета;

4. Список систем, с которыми будет необходимо взаимодействовать, их описание и технические данные.

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

Проектирование

TO BE или проектирование новых бизнес-процессов и пользовательских сценариев

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

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

Пользовательское требование руководителя дивизиона:

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

Возможные сценарии на основе этого требования:

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

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

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

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

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

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

Пример MVP:

Личные кабинеты:

• Генерального директора,
• Руководителя дивизиона,
• Менеджера продаж,
• Маркетолога (зачеркнуто),
• Сотрудника отдела логистики (зачеркнуто),
• Главного бухгалтера (зачеркнуто).

Примеры сценариев руководителя дивизиона:

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

Примеры сценариев дилера:

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

Функциональные требования

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

Пользовательское требование руководителя дивизиона:

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

Функциональные требования, которые из него вытекают:

1. Видеть общую информацию по отгрузкам дилерам своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города; конкретного менеджера;

д) конкретного дилера.

2. Устанавливать и менять план отгрузок на месяц для каждого менеджера дивизиона.

3. Видеть план компании по отгрузкам для дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) группы товаров (ССС, СЦС, ГСП, ПГП);

г) конкретного товара;

д) конкретного менеджера;

е) конкретного дилера.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/ города; конкретного менеджера;

д) конкретного дилера.

5. Видеть общую информацию о вторичных продажах дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/города;

г) конкретного менеджера;

д) конкретного дилера.

6. Указывать, сколько дилеров предоставили информацию.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/дивизиона и города;

г) конкретного менеджера;

д) конкретного дилера.

8. Видеть общую информацию о дебиторской задолженности дилеров своего дивизиона с возможностью множественного и одновременного выбора срока задолженности:

а) общая;

б) не более 14 дней;

в) 15-30 дней;

г) 31-45 дней;

д) 46-60 дней;

е) больше 61 дня.

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

а) периода времени (неделя, месяц, год);

б) региона/города;

в) конкретного менеджера;

г) конкретного дилера.

10. Видеть прогнозы отгрузок продукции от дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города;

д) типа транспорта;

е) конкретного менеджера;

ж) конкретного дилера.

Создание структуры системы, права пользователей

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

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

Пример структуры кабинета дилера, * отмечена версия MVP:

1. Страница авторизации*

2. Рабочий стол*

3. Моя компания

а) Профиль*

б) Договор и дополнения*

в) Коммерческие условия*

г) О компании*

сотрудники*

склады*

территория работы*

контракты других производителей*

специализированные подразделения*

требования и преимущества*

д) Грузополучатели*

е) Объекты*

4. Каталог

а) Список товаров

б) Корзина

в) Оформление заказа

5. Заказы и платежи

а) Мои заказы

заказы

отгрузки

б) Мои платежи

в) Дебиторская задолженность

5. Продвижение

а) POS-материалы

б) Акции

в) Бонусы

6. Сдать отчет*

7. Помощь*

8. Настройки*

9. Контакты*

10. Уведомления*

а) Автоматические уведомления*

б) Сообщения*

в) Написать сообщение*

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

Вот так могут быть заданы права:

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

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

Структура данных всегда представлена в виде схемы:



Советы:

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

Прототип интерфейса

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

Техническое задание

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

Отрывок из технического задания:

3.1.1.1.1. Склады

Основная часть страница включает следующие элементы:

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

название (адрес) склада;

город, в котором расположен склад;

площадь склада (кв.м.);

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

дополнительная информация: текст с описанием склада.

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

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

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

название (адрес) склада (текстовая строка)*;

город склада (текстовая строка)*;

собственный склад (чекбокс)*;

площадь склада, м2 (число)*;

дополнительная информация (текстовое поле).

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

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

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

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

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

Подытожим

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

Наш заказчик получил:

1. Личный кабинет для дилеров компании с возможностями:

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

делать предварительные заказы, тем самым предоставлять возможность планировать производство и транспорт для доставки,

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

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

2. Личные кабинеты сотрудников компании с возможностями:

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

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

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

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

хранить и обрабатывать результаты маркетинговых акций

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