Давным-давно, когда еще «1С:УНФ» называлась «1С:Управление небольшой фирмой 8 ред.1.1», а «деревья были большими» :) , к нам начали обращаться производители металлических дверей, которым нужна была автоматизация своей деятельности. Так получилось, что в регионе, в котором мы работали, было большое количество таких производителей.
Вели они учет своей деятельности по разному:
- кто-то на бумажках / карточках /амбарных книгах;
- кто-то в Excel 8.0 (Office '98);
- у самых продвинутых была «1С:Производство+Услуги+Бухгалтерия 7.7» (сами догадываетесь, какая – конечно «ломанная»).
Выслушивая «боли» клиентов - всем было предложено отказаться от использования нелицензионного ПО, приобрести «1С:УНФ» и начинать автоматизировать свой учет именно в этой конфигурации, так как именно она максимально закрывала все потребности Заказчика («1С:УПП» - не предлагали, т.к. для данных Заказчиков это было излишним и дорогим удовольствием – это «мелкий и средний бизнес»).
Вся автоматизация у клиента вначале сводилась к тому, чтобы в «Заказе клиента» нужно было указать от 6 до 10 параметров металлической двери (размеры, цвет, сторонность открывания и др.) и была печатная форма «Заказ клиента» с этими параметрами. Решалось это довольно просто и быстро без привлечения программистов - с использованием механизма «Характеристик». Учет в программе велся элементарный – в разрезе «Заказа клиента» + «Продукции»+ «Характеристики» этой продукции, весь производственный процесс велся как и раньше – «на коленках».
У клиентов начали возникать вопросы: «А зачем мы купили программу, которая нам закрывает только вопрос отслеживания Заказа, Оплаты и Отгрузки по нему? Хочу автоматизации и уйти от учета «на коленках».
Одной из болей, которая озвучивалась клиентами, – это расчет себестоимости готовой продукции в зависимости от параметров железной двери. И здесь начались доработки, причем у каждого клиента было свое виденье этого расчета и свои ключевые параметры. Вроде бы все они делали одно и тоже, а подход у каждого был свой.
Каждый месяц \ квартал количество этих параметров увеличивалось, а алгоритмы расчета усложнялись (забегаю вперед – за 10 лет количество параметров двери выросло с 10 до 140 и это не предел – даю гарантию 100%).
Реализация этих алгоритмов в «1С:УНФ» была возможна только через программирование, которое занимало достаточно длительное время и, как результат, стоило денег для клиента. Т.к. все эти параметры клиент сообщал не сразу, а в течении многих лет – код получался очень не красивый и многое решалось «через костыли» (программисты меня поймут). Часто клиенты обращались за исправлением своих же алгоритмов. Причины?:
- алгоритм расчета был ранее описан Заказчиком не верно;
- изменились и появились новые условия расчета;
- формы подбора параметров для пользователей не удобны (а как удобно – никто не знает и не говорит).
Эти постоянные доработки стали раздражать не только клиентов, но и программистов. Как результат – стресс для обоих сторон, отношения становились натянутыми и иногда очень накаленными. Почему?:
- потому что для клиента любые доработки - это затраты, время, убытки, нервные сотрудники;
- для программистов – это постоянный процесс «доработка \ отладка \ сдача работ \ исправление» математических формул расчета себестоимости в конфигураторе – очень «скучное» занятие. Кто-то даже выгорел и уволился. :(
К счастью, один из клиентов мой очень близкий товарищ – одноклассник, сосед по даче.
Одним прекрасным январским вечером после бани за кружечкой крепкого чая у нас зашел разговор о наших рабочих взаимоотношениях. Это у нас не принято, но разговор состоялся. Пришлось сидеть выслушивать «за всю нашу отрасль 1С». Но я рад, что этот разговор состоялся именно с близким человеком, а не сторонним Заказчиком, так как это дало мне толчок к пересмотру всего, что было сделано более чем за 10 лет у всех клиентов – производителей металлических дверей, с которыми мы работали.
Ночью меня осенило (прямо как Архимеда или Менделеева) :)
Все сложилось, разложилось по полочкам!!!
С этими идеями утром я «побежал» к товарищу. Разговор получился продуктивным - договорились о следующем:
- нужен такой инструмент, который позволит без привлечения программистов рассчитывать расход сырья в зависимости от параметров двери;
- т.к. количество параметров будет только увеличиваться – надо сделать инструмент, который позволит добавлять их без привлечения программистов;
- созданный инструмент должен позволять пользователям самим редактировать форму выбора параметров двери без привлечения программистов для возможности ее редактирования пользователями после добавления новых параметров;
- максимально привести будущую систему к типовой «1С:УНФ», для возможности автоматического ее обновления без привлечения программистов;
- я подготовлю перечень основных блоков автоматизации с кратким их описанием, а также бюджетом\сроками по их реализации и, по возможности, расчетом сроков окупаемости хотя бы первого блока. После этого снова встретимся – примем решение по дальнейшему сотрудничеству.
Где-то через месяц мы встретились снова (не в бане).
Были предложены следующие блоки для автоматизации в соответствующей последовательности:
- автоматизация работы менеджеров и экономистов;
- АРМ «Начальника производства»;
- АРМ «Рабочего» (с использованием штрихкодов);
- АРМ «Кладовщика» (с использованием штрихкодов);
- расчетный листок рабочего в АРМ «Рабочего».
- личный кабинет для оптовых покупателей – чтобы они сами могли играться параметрами двери, освободив частично от этого менеджеров по продажам.
Что было предоставлено клиенту:
- Графическая схема бизнес-процессов «Принятие заявки от клиента» и «Расчет себестоимости и конечной стоимости продукции» («Как есть» и «Как будет») - см. рис.1.
- Эскиз формы указания параметров двери (в тот момент их было всего 70, напомню сейчас их более 140 – см. рис.2, 3). Параметры были собраны со всех аналогичных клиентов (их было на тот момент 13). Параметры были проанализированы, систематизированы и нормализованы.
- Рассчитанный бюджет внедрения первого модуля и сроки реализации.
Сразу хочу сказать «ОГРОМНОЕ СПАСИБО» разработчикам «1С:УНФ» за то, что они к этому моменту реализовали механизм «Параметрических спецификаций» - вокруг него и была вся идея. В результате конфигурация останется типовой, а все реализуется используя типовые механизмы + расширение для прорисовки и сохранения формы выбора параметров.
рис.1. Процесс согласования «Заказа клиента»
рис.2. Справочник «Наборы дополнительных реквизитов»
рис.3. Текущая форма выбора параметров металлической двери (для менеджера)
Заказчик, ознакомившись со всеми предоставленными материалами и расчетами, сразу же согласился на первый этап и оплатил 100% озвученного бюджета со словами: «больше на этот этап не проси». Забегая вперед скажу, что бюджета мне не хватило и причина этого не в расчетах, а в моем перфекционизме (4 раза переписывали код, а также на первичную настройку\прорисовку выходной формы «Параметры спецификации» ушло очень много времени).
Что в итоге было сделано в рамках первого этапа с нашей стороны:
- создано расширение, позволяющее в пользовательском режиме редактировать форму «Параметров спецификации» и сохранять ее (типовой механизм формы для этого не подходит, т.к. такое количество параметров не умещается на одном экране и с ним работать просто невозможно. (см. рис.4-6). - Типовой механизм можно использовать, когда параметров у продукции не больше 10) - см. рис.7.
- настроена первоначальная форма «Параметров спецификации» исходя из 70 параметров на тот момент (см. рис.3);
- нормализован и заполнен справочник «Категории» - см. рис.8;
- частично наполнен справочник «Номенклатура» - см. рис.8;
- менеджеры обучены работе с обработкой по настройке формы «Параметров спецификации»;
- экономисты обучены работе в «Параметрическими спецификациями» в «1С:УНФ» и научились самостоятельно заводить нормативы cписания сырья и учета количества техопераций по указанным параметрам дверей.
Какие новые первоочередные задачи появились после выполнения первого этапа (естественно как доп.задачи):
- сделать ограничения при выборе номенклатуры в полях выбора, т.е. чтобы в поле «Краска» открывалась только краска, а не весь справочник «Номенклатура»;
- сделать печатную форму «Спецификация к заказу» (думаем пока как уместить все 143 параметра на 1 листочке, проектируем макет печатной формы);
- сделать печатную форму «Заказ-наряда» с разбиением по этапам производства и штрихкодами (думаем пока как уместить всю необходимую информацию на 1-2 листочках с разбиением по этапам производства, проектируем макет печатной формы).
рис.4. Обработка редактирования формы «Параметры спецификации»
рис.5. Форма редактирование свойства «Группировки» полей
рис.6. Форма редактирование свойства «Поля выбора»
рис.7. Типовой механизм отображения дополнительных реквизитов спецификации
рис.8. Нормализованные и заполненные справочники «Категории» и «Номенклатура»
Что в итоге получил Заказчик после выполнения первого этапа работ по внедрению «Параметрических спецификаций» в свой базе «1С:УНФ»:
- полностью работающий удобный инструмент для ввода требований покупателя к железной двери;
- длительность запуска в производство «Заказа клиента» от момента обращения Клиента сократили с 1 месяца до 1 часа (без учета оплаты);
- были сокращены расходы организации за счет сокращения 4 штатных единиц – 1 конструктора и 3 экономистов;
- окупились затраты раньше, чем планировали;
- лояльность своих клиентов;
- количество заказов увеличилось;
- отсутствие обследования и различных проектных документов.
Что в итоге получили мы:
- интересную творческую задачу;
- полностью работающий удобный инструмент, который можно применить не только к этому направлению производства, но и к другим, где количество параметров продукции больше 10;
- лояльность клиента;
- высвобождение программистов из сопровождения (на сопровождении теперь только консультанты);
- дополнительную загрузку для Джунов (консультации);
- отсутствие проектного документооборота с клиентом (обследования, моделирования, ТЗ, протоколы, статус-отчеты, управления рисками и пр. и пр.)
- новые задачи и продолжение проекта;
- ну и, конечно, АВТОМОБИЛЬ!!!
Резюмируя, хочу сказать – данный метод очень-очень частный случай - один из тысячи и не нужно стремиться к нему.
Чтобы можно было его применять как один из методов Agile – нужно ответить на следующие вопросы и по 10-ти бальной шкале оценить себя:
- Мы автоматизируем эту область много лет?
- Мы крутые специалисты данной области автоматизации?
- У нас команда «творцов», а не «исполнителей»?
- «Творцы» хотят творить в планируемый промежуток времени?
- Мы понимаем все «боли» сотрудников участка автоматизации?
- У нас есть виденье и идеи как «вылечить» сотрудников Заказчика?
- Мы с клиентом уже много лет?
- Клиент доверяет нам как самому себе?
- Мое отношение к бизнесу Заказчика - как к своему собственному?
- Заказчик не будет «докапываться до запятой»? (например, шрифт или цвет не тот)
Если у вас в сумме получилось 99 баллов и более – почему бы и нет, если меньше – это уже ваши риски.
