Картинка от Kandinsky.
Год назад, уволившись с работы, где проработал 10 лет, стал искать новую. Ситуация сильно поменялась. Если раньше требовались специалисты «все в одном», причем еще чтобы умел разговаривать с бухгалтерами на их языке, то теперь специализация. Аналитики беседуют с пользователями, программисты кодируют. Всесторонние знания должны быть у руководителя отдела, но такие места уже заняты, зачастую по блату, а взять себе возможного конкурента на позицию разработчика желающих нет.
На одном интервью на позицию программиста 1С спрашивают про опыт с sql. Рассказываю про интеграции, которые проводил с базами на ms sql, а также про сертификат Oracle DBA, который предусматривает отдельный экзамен именно по sql. Не моргнув глазом интервьюер заявляет: ну значит опыта с sql у вас нет, давайте заканчивать интервью.
На другом спрашивают по ЗУП, полчаса рассказываю о нестандартном расчете по предприятию с филиалами, который берет данные из других программ, считает по своим формулам и пишет в документы 1С, то есть по фэншую, чтобы можно было легко обновлять конфигурацию, о переносе всего этого с 2.5 на 3 версию. Об исправлении ошибки от 1С при расчете НДФЛ по филиалам, статье на Инфостарте. Интервьюер делает вывод: так, значит опыта по ЗУП у вас нет. Тут я уже не выдерживаю и спрашиваю: опыт это разломать стандартные механизмы? Отвечает, что в том числе и это.
О техническом интервью. Беседовала со мной девочка из отдела кадров, в конце предложила ответить на вопросы, которые ей приготовили коллеги из ИТ. Первый был: расскажите отличия справочника от документа и регистра, остальные были похожие. После 25 лет работы с 1С этот вопрос поставил меня в тупик. Что ей рассказывать и на каком уровне? Рассказал ей, как в 7.7 были справочники, а потом появились еще и регистры, но, видимо, мой ответ не совпал с тем, что у ней был, поскольку на дальнейшие интервью меня не позвали.
Вообще любят задавать дурные вопросы, пытаясь оценить уровень знаний, совершенно не понимая, что те проблемы, которыми они занимаются в данный момент, могут быть совершенно не актуальны для других организаций. В требованиях пишут опыт 1-3 года и перечисляются все знания, которые я приобретал годами и даже сверх того. Причем предполагается по умолчанию, что если у тебя не было опыта в какой-то узкой области, то ты его уже и не способен приобрести. Так если обмен по http ты не настраивал, поскольку в этом не было необходимости, то весь большой опыт интеграций другими способами не говорит ни о чем. Такое впечатление, что программистами работают автоматы, которым непостижимым образом заложили последовательность действий и они по ним работают, обучаться неспособны.
В большинстве вакансий указано: хорошее знание ЕРП, ЗУП, БП, УТ и прочего всего, зачастую все вместе. Что они под этим подразумевают? Боюсь, что даже разработчики данных продуктов не знают их хорошо полностью, а лишь ту часть, которую они разрабатывали. Если я несколько лет поддерживал конфигурацию, что-то дорабатывал, исправлял ошибки, то я могу заявлять что я ее знаю? А если один год? А если много, но в код не лазил? Или я должен знать как она устроена изнутри? Провести исследование всего кода? Они хотят за скромную зарплату нанять эксперта, который уже держит все эти знания в голове, и будет у них на побегушках? То есть противоречивые требования мирно уживаются в описании одной вакансии.
С удивлением узнал на одном из интервью в известной шинной компании, что аналитик и не должен быть программистом. Я понимаю, что выгодно разделение труда, специализация и все такое, однако получается как в монологе Райкина о костюме: одни пришивают пуговицы, другие рукава и т.д. Кто отвечает за результат? Аналитик побеседовал с пользователем, составил техзадание. Формально все правильно, что хотел пользователь описано. Кодер закодировал, согласно техзаданию, тоже все правильно. Но! Даже если способ реализации выбирает программист и делает это оптимально, велика вероятность, что задачу можно было решить по другому и более выгодно для бизнеса. Как часто при такой организации труда программист может влиять на саму постановку задачи? Из моей практики, сплошь и рядом, приходится выяснять у пользователя зачем ему это надо и надо ли вообще, бросать наполовину готовое решение, когда видно, что оно приведет к большим издержкам или рискам и пытаться вместе с пользователем переформулировать задачу исходя из возможностей конфигурации. Тогда зачем эта прокладка - аналитик? Она нужна, когда программист не умеет общаться с людьми и для избежания ответственности, ибо в такой схеме каждый сделал свое дело правильно. «К пуговицам претензии есть? Нет. пришиты насмерть, не оторвешь».
Также проработав последний год с РП от франчи, пришедшем из главбухов, при всех его неоспоримых знаниях и достоинствах, мои подходы к выполнению задач вызывали часто их(франчей) недоумение, поскольку эта двухзвенная схема не могла прийти к предлагаемому мною решению.
В итоге решил устроиться за меньшую, чем на предыдущем месте, оплату, на позицию рядового программиста на внедрение ЕРП на заводе, чтобы на практике изучить этот самый ЕРП.
Исходные данные:
Завод в Немоскве, численность работающих около 2000 человек, производит товары народного потребления и детальки для промышленности. ЕРП внедряется местным филиалом франчи известной фирмы. На проекте поменялось два руководителя со стороны заказчика и один со стороны франчайзи. Франчами было проведено полноценное обследование всех цехов, файлы занимают много мегабайт на диске(от заказчика это никто не читал, кроме меня). Используемые программы: для отдела продаж УТ 11, в бухгалтерии БП, ЗУП. Для оперативного учета используется программа на foxpro for DOS. Все это добро обменивается между собой по расписанию, причем данные вводятся в любую программу и появляются в других, конфликты разруливаются вручную.
Один программист на фокспро, один на 1С, два оператора по вводу данных. Было проведено обучение по курсу «Концепция прикладного решения 1С:ERP Управление предприятием» сотрудников всех цехов, которые будут работать с программой.
Одновременно со мной был принят еще один программист 1с, который тут же погрузился в текучку и особо вникать в ЕРП не стремился.
Руководил проектом со стороны заказчика программист 1с из другого города. Присутствовал на совещаниях по скайпу, подписывал документы. Все. Остальное делал РП от франчайзи.
Куратором был главный инженер, до установленного срока запуска оставалось два месяца. Побывав на совещании, я не понял вообще, что они обсуждают. Нет, все отдельные слова и предложения были понятны, но зачем и что делалось - нет. Люди не знали, чего от них хотят, все прослушали курс, а что конкретно будет каждый делать, не знали. Контрольного (сквозного) примера работы не было!
На Инфостарте есть статья Переход на современные ERP-решения «1С» – дорожная карта, кейсы, рекомендации, где описано, какие 10 составляющих важны для успешного проекта. В данном проекте все 10 пунктов оказались неблагоприятными.
Историческая система (Машина времени)
На самом деле программа была написана еще для ЕС ЭВМ, а потом уже переведена на персоналки 386. Целый отдел трудился в лучшие времена, но перейти с forpro for DOS на VFP почему-то не захотели. Программа включала все, потом из нее была выведена бухгалтерия и зарплата в 1С. Остался складской учет и производство. И остался один(!) программист foxpro, который мог что-то изменить в коде, и один программист 1С со знанием фокспро, который мог запускать ежедневные регламентные задания в этом фоксе и знал структуру таблиц. Таким образом, отсутствие на работе этого программиста по фокспро в течение определенного времени приводило к катастрофе. Исходя из этого задача стояла просто и незамысловато: внедрить ЕРП, чтобы избавиться от фокспро. Позже я несколько раз допытывался до целей проекта (может, еще расчет себестоимости или что еще, но нет - все устраивает, только это)
Поскольку руководитель проекта со стороны заказчика был полезен лишь для подписывания документов, а РП со стороны внедренца прекрасно видел грядущий крах этого проекта, было решено привлечь на помощь франчайзи двух вновь нанятых программистов у заказчика. И досталась нам разработка двадцати отчетных форм в ЕРП и чтобы было точно так же, как в исторической системе. При этом контрольного примера не было, структура данных в двух системах кардинально отличалась, то есть задача была очевидно невыполнимой.
Изменение подхода к внедрению
Доложив все это начальнику отдела ИТ, получил предложение самому заняться этим проектом. После обсуждений с франчи решили, что реально вытянуть можно начав внедрение с цеха ТНП (товаров народного потребления). Я составил план первого этапа, который включал переход одного цеха на ЕРП, причем вначале внедрить учет так, как было в исторической системе, то есть с упрощенными спецификациями. В спецификациях фокс были введены только те полуфабрикаты, в производстве которых участвовали другие цеха, а то, что производит сам цех ТНП сразу как материалы вводились на первый уровень спецификации. Утвердили план у директора. Зарплату установили мне такую же, как была на прошлом месте работы.
Куратором проекта стал сам директор, думаю, что это худший вариант, хуже только когда совсем нет. Если раньше главный инженер, не особо вникая зачитывал результаты прошлого совещания и требовал отчет о выполнении запланированного, разруливал конфликты, то теперь попытки что-то обсудить заканчивались так: «Вы что тут базар развели, идите там между собой разберитесь, а мне доложите, что надо делать».
Попытка внедрить ЕРП с минимальными изменениями
Когда я пришел на завод, отдел главного технолога радостно вводил в спецификации нормы трудозатрат. Чтобы зарплата потом автоматически рассчитывалась. Так как на это было выделено два человека и дело продвигалось с трудом, выходило, что закончат они эту работу по всему заводу за пару лет. Закрыл я эту активность. Также остановил все разработки по пожеланиям трудящихся, которых накопилось слишком много и которые в основном преследовали цель «чтоб было как в той программе», так что франчайзи на меня немного обиделись.
Первые два месяца франчайзи обучали пользователей цеха работе с ЕРП и пытались-таки создать контрольный пример, то есть пройти цепочку производства и движения по складам. Сам же я занялся фокспро, пытаясь понять, можно ли там что-то реанимировать и получить стабильно работающую систему.
Оказалось, что программа представляет собой набор файлов разных версий, причем никто не знает, почему сейчас используется именно текущая версия, вся документация была успешно отправлена на свалку во время переезда из одного здания в другое. И если по структуре файлов еще было понимание, что откуда берется, то как что считается, не знал никто. До обеда все цеха приносили в отдел ИТ данные по движению полуфабрикатов на бумажных талонах, там их забивали в систему, а после обеда начиналось священнодействие: программист фокспро запускал «задачи», то есть программы под номерами, которые что-то считали. На выходе появлялись текстовые(!) файлы, которые распечатывали на принтере формата А3 и раздавали в цеха, у кого стояли компьютеры, могли смотреть те же файлы у себя. Итого на выходе ежедневно имели остатки по полуфабрикатам в разрезе цехов с начала месяца, а после закрытия месяца списание материалов по нормам, которое шло в БП. Также плановая цена изделия рассчитывалась исходя из спецификации. План на месяц разузловывался до материалов и попадал в отдел снабжения. По окончанию месяца остатки загружались из БП и цикл повторялся. Загружать надо было, потому что отнюдь не все списания попадали в систему, а много чего заносилось сразу в БП.
Вернемся к ЕРП. По истечении двух месяцев выяснилось, что материалы должны как-то попадать в ЕРП, а вносить их кладовщики не могут, поскольку бумажки идут напрямую в бухгалтерию и там заносятся, естественно, с некоторым запозданием. Получается, что готовая продукция уже выпущена, а материал для ее изготовления еще не пришел, кроме того, надо отслеживать перемещение по складам. Но даже отключив контроль остатков, не удалось до конца сформировать ни один выпуск готовой продукции, хотя наколочено документов было много.
Запуск интеграций с другими программами
Решили настроить обмен БП =>ЕРП. Материалы, которые приходят на склад цеха ТНП, стали загружать из БП автоматически, вместе с перемещениями и цепочкой до приобретения у поставщика. Из фокспро загружался план. Первоначально франчайзи сделали выгрузку всех спецификаций из файлов старой программы. По мере изменения в данных, которые никто не отслеживал, оказалось, что спецификации изменились и надо загружать снова. Таким образом надо было либо вести реестр изменений либо вводить одно и то же в две программы. Некоторые спецификации не пересматривались годами и в итоге в производстве уже использовались совсем другие материалы. Выяснилось это уже в ЕРП, так как старая система хитрым образом обнуляла такие отрицательные остатки. Начал я с обработки, которая грузит спецификации по одной, показывая логические ошибки. По итогам списания материалов в производство выходили материалы, которых нет на складе, где-то полуфабрикат производил уже другой цех. Итого на проверку спецификаций у цеха по их оценкам ушло бы не менее полугода. Этим они занимаются и до сих пор. Запуск в производство и планирование главный диспетчер цеха вел в екселе, в фокспро шла информация только по выпущенной продукции, поскольку ЕРП формирует кучу этапов, среди которых очень трудно ориентироваться, франчайзи написали обработку для создания выпуска и завершения этапов с фильтрами. Тем не менее, диспетчер так и работает в двух системах. Я дал добро закрыть любые часы, лишь бы было так же удобно, как в екселе, но результата не получил.
Кадры решают все
Мотивация. Тут просто. Ее нет.
Читал я про успешное внедрение ЕРП, где радостно рапортуется, что 60% кладовщиков не смогли перестроиться, чтобы работать с новой системой, и были заменены. На данном предприятии такого представить себе было невозможно. В цехе имеется два конструктора, которые кроме своих специфических функций выполняют также оформление кучи бумаг по товародвижению, работе с рекламациями и прочее. При переходе на ЕРП проверять спецификации им было некогда. Так что поскольку я был заинтересован в успешном внедрении, это делал я, насколько мог. Вакансия конструктора как была открыта при моем приходе на завод, так и сейчас они ищут. Оператора ввода данных искали также с самого начала. Сменилось три. Водителей погрузчика по штату в цехе три, остался один.
Поскольку из всех работников цеха умел работать с ЕРП один конструктор, то и система оказалась построена под него. Попытки уйти от детализации до гаечек и болтиков и списывать такие материалы раз в месяц, а не указывать в каждой спецификации, были категорически отвергнуты. Есть желание, чтобы конструкторская спецификация как есть была в ЕРП. Наверное, не надо объяснять, к чему это ведет.
Неудобства и загадки ЕРП
Если в фокспро один полуфабрикат имеет один код и проходит по цехам с ним вплоть до сборки, согласно расцеховке, то в ЕРП мы вынуждены вместо одного вводить для каждого цеха свой: пластина, пластина с дырочками, пластина после гальваники и так далее. При этом если вводить полуфабрикат на закладке «Побочный и промежуточный выход», то при закрытии месяца его стоимость не рассчитывается. Пришлось для каждого полуфабриката вводить свою спецификацию для каждого цеха отдельно.
Формируется вал документов, в которых пользователи путаются.
Старая база занимает смешное место на диске, даже если хранить все копии за года, работает на 386 компьютере и быстро. ЕРП требовательна к ресурсам.
Чтобы посчитать плановую цену продукции, вроде бы есть Плановая калькуляция, однако если вы думаете, что она просто развернет спецификацию и укажет количество и стоимость материалов, то это не так. Там при выводе накладывается куча фильтров, то ли учитываются остатки на складах, а остальное отбрасывается, то ли что еще, внятного описания нет. В результате плановая стоимость получается всякий раз разная и не равная сумме входящих в изделие материалов. Франчайзи тоже не пользуются этим механизмом и сами проводят разузлование.
Первый же расчет плановой себестоимости привел экономистов в шок. По произвольно выбранному изделию себестоимость была на 40 процентов меньше, чем в старой системе. Оказалось, что два материала просто не вошли в спецификацию. Франчайзи достали свои файлы, из которых делали загрузку, и доказали, что на тот момент в фокспро также не было этих материалов.
Если раньше экономисты нажимали кнопку и получали распечатку входящих материалов и итоговую себестоимость, а что там в нее входило, оставалось за кадром, то теперь ошибки стали видны. Ресурсов и желания проверять все спецификации у экономистов не было, и встал вопрос, кто в таком случае будет отвечать за неверные данные. В старой системе экономисты не видели ошибок, если бы они вылезли, виноваты были бы конструкторы. Сейчас ответственность падала и на них. На момент моего ухода с завода решили считать пока в старой системе.
К чему пришли в итоге
Посмотрев на АРМ для диспетчеров от франчи, я не понял, как с ним работать, запросил описание и инструкцию и снова не понял. А два диспетчера были близки к пенсии и весьма далеки от компьютера. Поскольку увольнение даже одного из диспетчеров ставило крест на проекте, решил я им облегчить жизнь. При этом пришлось переписать программку по вводу талонов на перемещение полуфабрикатов, потому что оператор в ИТ отделе обладал особыми знаниями, как с ней работать, то есть даже для меня было не очевидно, как вводить эти талоны. Потом пришлось переписать ее уже на visual foxpro, чтобы работало на 64-битных операционках. В итоге диспетчера вводят талоны, к которым они привыкли за много лет, далее автоматически формируются перемещения в ЕРП и под них создаются заказы на производство и этапы производства, отчеты по движениям полуфабрикатов выводятся из обоих систем в ЕРП, при поступлении полуфабрикатов из других цехов предполагаем, что они их там выпустили, и делаем этапы, материалы для этого получаем «Оприходованием товаров», то есть оставляем другие цеха в серой зоне. Таким образом переучивать диспетчеров сильно не пришлось, и работы им много не добавилось, так что недовольства переходом на новую программу с их стороны не было.
Также сделал автоматическую загрузку выпуска готовой продукции из старой системы и формирование под это заказов и этапов. В итоге за два месяца загрузил в копию данные и получил в основном совпадающие результаты по списанию материалов по нормам, закрыл месяцы и рассчитал себестоимость. Встал вопрос о проверке. В цехе сказали, что они заняты другими делами и сверять им некогда. Директор вообще не понимал, зачем необходимо это сверять. По счастливой случайности на практику пришли студенты, с ними мы прошли по всем расхождениям и доказали, что ЕРП выгружает правильно, и с этого момента выгрузка в БП пошла из новой системы.
Особенности национального учета
Традиционно листовой металл продается и списывается в килограммах и тоннах. Однако отдается в производство в листах. Я дописал в документах ЕРП возможность списания и получения в листах, исходя из размеров и плотности, что вызвало искреннее недоумение в цехе. В ЕРП со складов типа цеховая кладовая материал автоматически списывается в производство по нормам. В старой системе весь склад цеха фактически являлся цеховой кладовой. Таким образом, кладовщик не принимал никакого металла и не отдавал его в производство. Его функция была сосчитать, сколько там имеется в наличии, и доложить, чтобы производство не остановилось. Когда снабженцы видели, что по остаткам в программе висит куча металла, а фактически его нет, они пинали цех и те начинали списывать брак, металлолом и подгонять программу под факт.
Директор утвердил в новой программе схему с разделением склада и цеховой кладовой, однако попытки внедрить ее наткнулись на глухой саботаж. На совещаниях цех докладывал, что они так и работают, фактически же так же подгоняли данные в программе исходя из своих соображений. Мои призывы на совещаниях хотя бы разложить металл в стопки по номенклатуре и установить таблички были отбиты тем, что и так все знают, как определить марку металла (при том, что дикий пересорт в программе) и к тому же вместо трех водителей погрузчика у них работает один, поэтому наводить порядок на складе нет никакой возможности. Таким образом я наблюдал парадоксальную ситуацию, когда учитывается, как каждая копеечная гайка путешествует из одного цеха в другой: склад, мойка, гальваника, сборка. В то же время металл, составляющий основную часть стоимости изделия, фактически не учитывается при приеме и передаче в производство, берут сколько хотят.
Вообще обычной была ситуация, когда программисты обнаруживают какую-то проблему в учете, а вместо решения,чтобы запрограммировать логику работы программы, сотрудники заказчика пытаются просто игнорировать проблему. Найти человека, который принимает решение невозможно, никто не хочет брать на себя ответственность за изменение бизнес-процесса вплоть до главных лиц завода. Упорное игнорирование неприятного при внедрении и как с ним бороться, наверное, заслуживает отдельного исследования. Обычная позиция: «Мы вам платим деньги, вы сделайте, чтобы программа работала». Люди ожидают, что после внедрения волшебной программы произойдет какое-то чудо, которое улучшит их производство, при этом сами не желают ни сформулировать цели, которых они хотели бы достичь, ни навести элементарный порядок в своих действиях.
Тем не менее программа работала, мелкие замечания постепенно сходили на нет, я уже готовился резюмировать окончание первого этапа и соответственно пересмотр зарплаты и дальнейшее расширение на другие цеха, но...
Маньчжурский кандидат
На одном из совещаний директор спросил: «Вот вы внедряете ЕРП уже столько месяцев, а где же конкретный результат? Остатки незавершенного производства в виде полуфабрикатов разной степени готовности как лежали в проходах в цехе, так и продолжают лежать». Рецепт у него уже был. Это ввод детальных спецификаций и учет всех полуфабрикатов в режиме реального времени. Тут я достал подписанный в самом начале план, где было написано про запуск системы на первом этапе с упрощенными спецификациями. Об уменьшении НЗП там не было ни слова. Надо отметить, что в течении нескольких месяцев, когда цех не мог проверить используемые в работе спецификации и сверить результаты выгрузки в бухгалтерию, один из двух конструкторов цеха плюс прикомандированный из отдела главного конструктора занимались вводом детальных спецификаций (сказали, что по указанию директора). То есть проектом рулил кто-то другой.
Выяснилось, что бывший зам.директора, давно работающий в другом месте, по старой дружбе иногда посещал завод и высказывал свой взгляд на информационные процессы, который не совпадал ни с моим, ни с мнением франчи. И мне удалось с ним встретиться. Когда я спросил, почему вы хотите внедрить детальные спецификации, то был остановлен: «Я ничего не внедряю, это цех внедряет». Также оказалось, что вести учет полуфабрикатов в реальном времени это совершенно плевое дело, надо только дать мастерам бумажки, где они будут все отмечать, а потом кто-нибудь введет эти данные. И еще не надо слушать жалобы, что в цехе не хватает работников даже по штату, это они всегда ноют, справятся.
Оценив перспективы, понял, что дальше оставаться в этом проекте в роли клоуна мне уже не хочется. В итоге денег не заработал, кроме того, 370 часов за полгода отработал сверхурочно и бесплатно, надеясь, что после успешного внедрения первого этапа будет легче. Потратил кучу нервов на преодоление саботажа. Ночью снились спецификации. И бессонница. Даже запись в трудовой книжке осталась просто инженер-программист, вместо фактически выполняемой работы руководителя проекта и главного программиста.
Через два месяца после моего увольнения ЕРП в цехе так же работает. То есть цель первого этапа перехода с фокс на ЕРП, считаю, выполнена. Каким образом франчайзи будут дальше развивать проект, не представляю, поскольку отходить от своего подхода они не хотят, то есть даже работать с фокс через com-соединение отказываются. Дайте нам файлы, мы их загрузим, а лезть в ваш фокс не будем. Оставшийся на заводе программист 1С хоть и работал в далекие времена с фоксом, сразу при приеме отказался работать с ним. Дураков нет.
