Кирилл Соловейчик: "Производство — это самое главное, и начинать нужно с него"

Готовя этот номер, мы поставили себе задачу рассказать о самых мощных ИТ-системах и самых передовых 

Кирилл Соловейчик,  генеральный директор «ЛЕНПОЛИГРАФМАШ»

Рис. 1. Ведение спецификации изделия

Рис. 2. Маршрутные карты

Рис. 3. Отчет о выполнении производственных операций

Рис. 4. Анализ объема производства по операциям, заказам и цехам

Рис. 5. Анализ ФЗП

машиностроительных предприятиях, автоматизировавших управление производством. Уникальная по мощности и функциональности система «КАСКАД» создана на заводе «ЛЕНПОЛИГРАФМАШ». Из всех решений по автоматизации машиностроительных предприятий, с которыми нам приходилось сталкиваться, это более всего поражает воображение уровнем детализации и охватом производственных задач. На наш взгляд именно «КАСКАД» ближе всех подошёл к идеалу автоматизированной системы для промышленного предприятия. О ситуации на заводе, об основных задачах и о сложности автоматизации машиностроительного предприятия с давней историей рассказано в статье Кирилла Соловейчика, генерального директора «ЛЕНПОЛИГРАФМАШа», «Развитие ИТ на предприятии в условиях ограниченного бюджета» (см. IE, №15/2005). В этом номере мы публикуем более подробное описание возможностей системы «КАСКАД» и интервью с ее идеологом — Кириллом Соловейчиком (с ним можно связаться по e-mail: kirill@spbcioclub.ru).

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

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

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

При этом развитие функциональности модулей также проходило постепенно, и конструкторско-технологический модуль — яркий тому пример. На первом этапе данные спецификации изделия не содержали в себе никакой информации о его жизненном цикле. И только после успешного запуска модуля учета производства, на втором этапе, мы столкнулись с необходимостью разработки так называемого «исторического движка» — функционала учета изменения спецификации во времени. Сейчас в системе уже есть 3D-модель и чертеж изделия, но эти и прочие данные САПР были включены в неё после 2004 года.

Однако «КАСКАД» не интегрирован с конструкторским программным обеспечением. Я не считаю целесообразной интеграцию подобных комплексов с управленческой системой учета ввиду сложности самого процесса, а также с точки зрения баланса функционала системы. «КАСКАД» — это управленческая система, и вся конструкторская и технологическая информация в ней присутствует, а большего для управленческого учета не нужно. Мне кажется, есть гораздо более актуальные направления её развития.

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

Внесение данных в систему — это непростой момент, и здесь тоже нужна система приоритетов. При запуске конструкторско-технологического и производственного модулей часть данных уже была внесена в систему предварительно путем их конвертации из старых систем учета, а остальные данные по спецификации изделий и технологическим картам вносились по ходу опытной и затем промышленной эксплуатации. Что вносили в первую очередь? Прежде всего были необходимы данные о деталях и структуре изделий, а также нормы расхода материалов на их производство. Причем на этом этапе спецификации изделий создавали не конструкторы, а производственники, так как производственные отделы испытывали необходимость в данных в большей мере. Конструкторы работают в отдельном конструкторско-программном комплексе, готовят чертежи и документацию, а по окончании работ всю информацию в электронном и бумажном виде сдают в специальное бюро. Вот на этом этапе электронная информация поступает в «КАСКАД».

Данные вносились сразу по всем изделиям?

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

Да, старые машины при запуске системы уже практически снимались с производства, но такая тактика дала очень важный эффект: система сразу показала реальные объемы производства и «незавершенки». Ведь в производстве нет такого дня, с которого все начинают жить по-новому. Запуски новых изделий всегда накладываются на доработку старых. Если бы в системе были только новые изделия, я не смог бы отразить в ней полную ситуацию на производстве. В нашем случае сошлись все объемы, и все увидели, что система дает реальную картину. И показать это было очень важно для успеха проекта.

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

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

Как в системе реализовано производственное планирование?

Для любого директора задача планирования является первоочередной, ведь оптимизация загрузки мощностей дает прямую выгоду. Но планирование — это очень емкое понятие. Прежде всего мы создали функционал анализа изменений в конструкции — это простая оптимизация на первом уровне. Каким образом? Допустим, мы знаем, что и когда надо запустить в производство. Это значит, что уже можно формировать производственный план. Например, я хочу такого-то числа запустить определенные модификации изделий в определенном количестве. Система анализирует все данные в этой спецификации, находит основные детали, производит расчёт и формирует необходимую партию. Она сообщает, что деталь А входит в такие-то машины с такой-то применяемостью, а деталь В — в такие-то, и т. д. Объем производства растет, и сейчас планировщики уже практически не могут решить эту задачу вручную. Ведь нужно взять каждую маршрутную карту изделий текущего запуска и проанализировать, входят в неё эти детали или нет. Человеку это уже не под силу, а машина все быстро посчитает.

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

Кроме загрузки ресурсов система формирует статьи себестоимости изделия, дефицит материалов, бюджетные фонды и рассчитывает, что, например, такие-то комплектующие надо заказывать за три месяца со 100%-ной оплатой. А при планировании производства на год формируются годовые бюджеты — на комплектацию, на материалы, на трудовые ресурсы и т. д. И всё это информация для принятия решения о приемлемости такого плана производства.

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

Она служит инструментом для оптимизации, но несколько с другой стороны. На самом деле оптимизация производственного плана — это тяжелая задача, ведь все операции имеют разную трудоемкость, ресурсы, станки и люди тоже разные. Конечно, можно выстроить систему тотального контроля, контролировать выполнение каждой операции, но после какого-то момента качество начнёт падать. Это доказанный принцип TQM (Total Quality Management). Проанализировать загрузку станков, чтобы увеличить их выработку, нетрудно, но станки после этого будут ломаться в два раза чаще. Когда ты пытаешься исключить человеческий фактор, люди сами найдут тысячу способов сделать так, чтобы этот станок не работал. Мы живем в России, и нельзя это списывать со счетов.

Все говорят, что суточное задание на день за мастера должна выписывать машина. В идеале это было бы очень хорошо. И в системе «КАСКАД» всё для этого есть — стоит лишь сформировать необходимый документ. Но я его не формирую, я даю мастеру возможность сделать это самому. Метод кнута в России не эффективен, поэтому я решил поступить по-другому — наоборот, стимулировать сотрудников к эффективной работе. Принцип таков: сделаете быстрее — получите соответствующую премию. Самые большие временны’е затраты — это время пролеживания детали между операциями и цехами. И его, конечно, надо сокращать. Однако никто, кроме самих мастеров и начальников цеха, не знает, как сделать это лучше. Им известны все нюансы и взаимосвязи. Значит, пусть они и решают, а система предоставит им необходимый инструмент. В «КАСКАДе» содержится информация не только о дате, но и о времени, когда проходила каждая операция по каждой детали, каждому изделию и каждому запуску. Мы накапливаем статистику о том, сколько на самом деле выполнялась обработка деталей по операциям, от первой отрезки заготовительного материала и до окончания, и менеджеры производства всегда могут ее по­лучить.

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

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

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

Конечно, на начальном этапе, при запуске, ошибок было немало. Но в качестве их контролера выступала сама система — она сводила данные и определяла несоответствия и противоречия. В ней для этого существует целая система агрегированных журналов. Когда мы замечали ошибки, то собирались со всеми заинтересованными сторонами и разбирались, почему это произошло. Сейчас такие ситуации очень редки. Что касается сложностей, то очень важный момент — модуль расчета зарплаты. Зарплата на предприятии и сдельная, и повременная, и учесть все нюансы очень непросто. Табели, периоды закрытия, графики работы, премиальные фонды, авансы, профсоюзные выплаты. За период по всему заводу набирается около ста различных видов выплат и столько же удержаний. Как только принимается решение о том, чтобы оплатить ту или иную работу, система проставляет даты на выплату фондов, и все это передается в бухгалтерию. Причем детализация выплат позволяет дойти до каждого сотрудника со всеми его категориями, отклонениями, видами оплаты и шифрами. Именно через зарплату система сама заставила себя дорабатывать — в какой-то момент рабочие отказались делать детали, которые не внесены в неё, потому что поняли, что сдельная зарплата рассчитана не будет. Кстати, в «КАСКАДе» нет бухгалтерских расчетов. Имея продукты «1С», дублировать их глупо. Есть система задокументированных шлюзов, через которые информация передается в систему «1С: Предприятие» и обратно.

Детализация производственного учета в системе «КАСАКАД» — практически 100%. Данные можно анализировать во всех мыслимых разрезах. Это закладывалось сразу или развивалось эволюционно? И как можно сделать такую систему за столь короткий срок? Ведь подобный по мощности функционал ERP-вендоры разрабатывают годами…

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

Что касается сроков… Я уверен, что компаний нет — есть люди. В истории компьютерной техники масса примеров, когда успех определял один человек. И мне повезло: у меня были ресурсы и соответствующие полномочия в компании, я разрабатывал систему в ранге первого заместителя генерального директора. Рядом был программист, профессионал высочайшего класса, к тому же понимавший меня с полуслова и проработавший со мной много лет. Была воля к победе и огромный труд.

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

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

Мне кажется, он определяется стилем руководства генерального директора и его отношением к предприятию. Конечно, деньги — это главное, но прежде всего директор должен знать, что у него происходит в самом сердце завода, где, за счет чего и как образуется добавочная стоимость. Взяться за производство труднее психологически, ведь здесь приходится глубоко, буквально с головой погружаться во множество проблем, а это требует времени и многих останавливает. Зачем это нужно, если завод работает, продукция выходит? Да к тому же большой риск, ведь можно всё разрушить, не создав ничего нового…

И к сожалению, многие директора машиностроительных предприятий не понимают, что ИТ могут сильно помочь. С момента моего прихода на завод мы увеличили выпуск изделий на пару порядков, сохранив ту же самую крайне низкую численность управляющего аппарата. Конечно, без «КАСКАДа» с такими ресурсами было бы физически невозможно учитывать всю выпускаемую номенклатуру. Раньше сотрудник два дня тратил на то, чтобы записать в журнал, что нужно для сборки, чтобы посчитать всё это, а сейчас достаточно одной секунды — нажать кнопку, запустить анализ склада и распечатать.

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

В целом функциональную архитектуру системы «КАСКАД» можно разделить на несколько модулей, из которых основополагающими для промышленного предприятия являются конструкторско-технологический, отвечающий за ведение спецификации изделий и технологических маршрутов, и производственный. Такое деление вполне традиционно для машиностроительных заводов. Многие компании идут тем же путем, но с одним принципиальным отличием: как правило, они предпочитают автоматизировать конструкторско-технологический блок на базе решения класса PDM и интегрировать его с ERP-системой. Практически все проекты, которые мы обсуждаем в рамках этого номера, придерживаются подобной тактики, причём в некоторых случаях внедрение PDM-систем предваряет ERP-проекты. Однако в «КАСКАДе» оба этих модуля изначально разрабатывались в тесной связи друг с другом, более того, и развитие необходимого функционала шло параллельно. Всё это обеспечило удивительно гладкое, бесшовное их взаимодействие. В соответствии с такой архитектурой в системе реализованы два исторических «движка». Один следит за спецификацией изделий и историей ее изменений. Второй — за изменениями непосредственно в производстве, которые могут быть вызваны изменением маршрутных карт, ручным запуском дополнительного изготовления некоторых деталей и т. д.

Конструкторско-технологический модуль

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

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

Система «КАСКАД» позволяет проанализировать и плановую себестоимость изделия. Формируются детализированные отчеты о расчетной трудоемкости и стоимости по конкретному продукту, по тому или иному виду работ, участку или цеху. Другой пример: у технологов есть журнал диспетчеризации выпуска и ремонта оснастки, и система может предоставить отчет о том, какой экономический эффект предприятие получило от ее внедрения. Зная, сколько времени занимало изготовление детали в предыдущем варианте, система накапливает данные о продолжительности её производства с новой оснасткой и после этого выдает экономический эффект.

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

Запуск изделия в производство

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

Алгоритм запуска изделия на внешнюю кооперацию сложнее. В этом случае ответственность за часть деталей перекладывается на отдел внешней кооперации. А поскольку в текущей спецификации всё расписано для условий основного завода (станков, оснастки и т. д.), то передавать ее в полном объеме не имеет смысла — на другом заводе все равно всё будет свое. Поэтому создается специальный перечень деталей с промежуточной спецификацией для каждого из них, достаточной для того, чтобы эту деталь запустить на другом заводе. «Этот вариант сейчас вызывает все больший интерес, — комментирует ситуацию Кирилл Соловейчик. — Наши собственные цеха просто не справляются с объемом, несмотря на рост численности персонала и станочного парка. К тому же мы видим изменения в экономике, подталкивающие предприятия к широкому использованию аутсорсинга».

Что происходит с изделиями, запущенными в производство? На основе нормативов система планирует даты производства деталей и дату сборки изделия. Фактически осуществляется планирование производства от даты запуска с учетом последовательности изготовления деталей и необходимой оснастки и с учетом нормативной загрузки производственных мощностей. Это очень похоже на MRP-планирование, но с более глубокой детализацией производственного плана — вплоть до каждого задействованного участка и станка.

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

Однако функции детального планирования в «КАСКАДе» развиты не так сильно, как в тиражных ERP-продуктах. И это совсем не случайно. «Первоочередной была задача анализа производства, а не планирования, — поясняет Кирилл Соловейчик. — Сначала необходимо собрать максимальную информацию о ходе производства и проанализировать ее. Это актуально для большинства предприятий. А уже затем заняться планированием. Это мне кажется более правильным, и сейчас мы уже заканчиваем модуль планирования».

Производственный учет

Учет фактического хода производства в «КАСКАДе» организован параллельно по двум направлениям, что дает возможность дополнительного контроля за достоверностью введенных данных. Прежде всего — как только деталь обработана и попала в ОТК, его сотрудники отмечают в системе выполнение каждой операции по ней. При этом существует входной контроль, есть журнал предъявлений (первое, второе и т. д.) и возможность фиксировать и анализировать брак. Кроме того, через некоторое время выполнение операции отмечает экономист цеха для проведения оплаты. Это происходит несколько позже отметки ОТК и позволяет дополнительно проконтролировать скорость ведения производственного учета. А поскольку экономист в цехе и сотрудник ОТК вводят по сути одну и ту же информацию, но в разных разрезах, ведется специальный журнал расхождений.

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

По словам генерального директора «ЛЕНПОЛИГРАФ­МАШа», утро все начальники цехов начинают с анализа работы в предыдущий день. Как и в других модулях системы «КАСКАД», эти отчеты можно посмотреть во всех мыслимых разрезах: по участкам, изделиям, деталям, операциям, профессиям, конкретным рабочим. Можно просмотреть лицевой счет рабочего — какие операции, по каким деталям и по каким заказам он выполнил за выбранный период.

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

***

Повторимся: детализация производственного учета в «КАСКАДе» поражает, она практически стопроцентная. Более того, описанными здесь модулями система не ограничивается. В ней есть всё необходимое для автоматизации работы отдела закупок (с контролем и анализом минимальных средневзвешенных и максимальных цен за период), отдела сбыта (с контролем хода договорного процесса), отдела внешней кооперации (с критериями оценки успеха) и полного цикла формирования сдельной и повременной заработной платы и учета кадров. Кроме того, в системе «КАСКАД» реализовано бюджетирование всех статей затрат предприятия (включая лимиты на канцелярские товары и расходные материалы, социальные расходы и т. д.), учет ремонта оборудования и загрузки автотранспорта и даже деятельности по сдаче помещений в аренду, службы поддержки пользователей компьютеров, электронной проходной и работы заводской столовой. На сегодняшний день в планах генерального директора «ЛЕНПОЛИГРАФМАШа» — ее дальнейшее развитие, прежде всего создание дополнительного аналитического модуля, позволяющего анализировать накопленный массив данных. И некоторые работы в этом направлении уже сделаны (см. рис. 4 и 5).