| О корпорации | О системе | О представительстве | Материалы | Координаты | Сайты | Партнеры | Клиенты | Ссылки |
Интервью с президентом корпорации «Галактика» Николаем Красиловым
Когда номер очередной версии того или иного программного продукта меняется «в первом знаке», это всегда вызывает повышенный интерес со стороны его нынешних и потенциальных пользователей. В дни, когда завершается работа над системой корпоративного управления «Галактика» 7, редактор PC Week/RE Сергей Свинарев попросил ответить на ряд вопросов президента корпорации «Галактика» (www.galaktika.ru) Николая Красилова.
Николай Красилов: В ней существенно усилен контур планирования и управления производством. Сегодня есть все основания утверждать, что «Галактика» 7.1 поддерживает стандарты MRP-II. В настоящее время, когда многие предприятия реального сектора развиваются очень динамично, спрос на подобные системы достаточно велик. В каком-то смысле мы возвращаемся к тому, с чего начинали. В этом году «Галактика» отмечала свое пятнадцатилетие, и я вспоминаю, что, когда мы пришли к первым заказчикам, тех интересовали не проблемы автоматизации бухгалтерии, а вопросы управления производством, определения системы норм и нормативов, формирования заказов, исчисления себестоимости, осуществления объемно-календарного планирования и т. д. На какое-то время данные вопросы по известным причинам отошли на второй план. Сегодня мы возвращаемся к ним, вооружившись самыми современными методологиями и изучив опыт ведущих западных разработчиков. За плечами наших аналитиков и программистов годы напряженной работы. Думаю, для корпорации «Галактика» это крупнейшая веха в ее развитии.
Н. К.: Поскольку основные изменения в версии 7 затронули модули управления производством, хотелось бы напомнить о принятой в отрасли и у нас в «Галактике» классификации подобных систем. Во-первых, следует отличать предприятия с непрерывным и дискретным производственным циклом. Затем надо учитывать особенности выпускаемой продукции и характер ее сбыта: производство на склад, либо сборка, производство или конструирование под заказ. И, наконец, существуют отраслевые особенности, которым тоже должна удовлетворять внедряемая ERP-система. В реальной жизни мы имеем дело с всевозможными сочетаниями параметров этой трехуровневой классификации, а кроме того, необходимо в каждом проекте проводить тонкую настройку с учетом особенностей бизнес-процессов и выпускаемой продукции.
Это означает, что выпускаемый нами продукт должен быть достаточно функциональным и гибким, чтобы закрывать потребности большинства предприятий. Если на машиностроительном заводе требуется полноценное планирование всех ресурсов, то нефтеперерабатывающему комбинату функции MRP фактически не нужны: для этой цели там применяются специализированные системы управления технологическим циклом. Тем не менее модули управления финансами, логистикой, кадрами, предлагаемые «Галактикой», там вполне могут использоваться, если их интегрировать со специализированным производственным контуром.
Н. К.: Они весьма существенны. Например, при массовом производстве планируется производственная программа для стандартного изделия, которая призвана обеспечить нужный объем выпуска, но она не должна учитывать требования отдельного клиента. А в случае изготовления партий на заказ, ресурсы планируются под каждую партию и требования конкретного клиента через ERP-систему спускаются до уровня подразделений. При этом приходится особым образом составлять план закупок, поскольку некоторые комплектующие на предприятии могут просто отсутствовать. Если речь идет не о сборке, а об изготовлении изделия на заказ, то появляется дополнительный этап проектирования и процедура планирования еще более усложняется. При наличии большого портфеля заказов целесообразно планировать не выполнение каждого из них в отдельности, а формировать на их основе сводную производственную программу.
Наша система планирования учитывает лишь реально существующие производственные ресурсы, но если загрузка определенного типа оборудования будет регулярно выходить за пределы имеющихся возможностей, это может стать толчком к принятию решений о закупке, к примеру, дополнительных станков или изменении структуры технологических подразделений.
Н. К.: Проектируя архитектуру своей системы, мы имели в виду все понятные нам типы и виды производства. Еще ни одному разработчику ERP-систем не удалось в равной степени «закрыть» все многообразие потребностей потенциальных заказчиков. Именно поэтому мы уделили особое внимание гибкости нашей системы и открытости ее архитектуры для настроек и развития. Концептуально она основана на технологическом ядре и инструментарии-конструкторе. Ядро содержит базовые объекты, с помощью которых можно построить систему автоматизации управления всеми основными видами производства. Число подобных объектов достаточно велико. Примером могут служить такие объекты, как план, заказ, отчет.
Следует отметить, что объектный подход в версии 7 получил очень большое развитие. Достоинства объектного подхода хорошо известны программистам: объекты используются многократно, их легко настраивать и модифицировать, на их основе можно строить сложные структуры, наследующие общие свойства. Наряду с ядром, мы создали набор системных алгоритмов, которые оперируют базовыми объектами и имеют множество настроек. Посредством настроек системные алгоритмы нетрудно приспособить для управления самыми разными типами производства. В отличие от ядра, набор системных алгоритмов открыт для наращивания, а это означает, что в случае необходимости мы можем дописать нужный алгоритм и удовлетворить таким образом потребности конкретного заказчика. Тот, в частности, манипулируя только настройками, легко определит, будут ли все заказы консолидироваться в одну производственную программу.
Есть, например, алгоритм ERP-планирования или алгоритм планирования ресурсов. Строго говоря, алгоритмы тоже состоят из объектов, которые обращаются к другим объектам, в частности к объектам ядра. В этом смысле объектный подход пронизывает всю архитектуру «Галактики». Как правило для учета особенностей предприятия должно хватать настроек системных алгоритмов, но если их будет недостаточно, придется дописывать новые, и только в таком случае потребуются профессиональные программисты (это могут быть специалисты заказчика, партнера или наши разработчики). Мы делаем объектную инфраструктуру «Галактики» полностью открытой: каждый заказчик получает ее описание и может работать с объектами по своему усмотрению. Объектная архитектура гарантирует, что, дописывая нужные ему функции, сторонний разработчик не разрушает систему в целом. Пока что открыта только объектная инфраструктура контура управления производством, но со временем такой подход будет распространен на всю линейку «Галактики».
Н. К.: На уровне инструментов, которыми пользуются разработчики, объектный подход применяется нами еще с 1994 г. В системе «Галактика» есть свой 4GL-язык VIP, в течение восьми лет он целенаправленно совершенствовался и становился все более объектно-ориентированным. Сначала объекты были низкоуровневыми и обеспечивали, например, работу с пользовательским интерфейсом. Уже тогда использовался механизм обработки событий.
Начиная же с «Галактики» 7 мы имеем полноценную объектную архитектуру и существенная часть продукта (контур управления производством) реализована новыми средствами. У нас есть четкий план переноса и остальных частей «Галактики» в объектную среду.
Н. К.: Они позволяют нам легко наращивать число аналитических признаков, присущих каждому объекту, и использовать их при планировании. Например, если объекту «заказ» присвоить дополнительный признак, характеризующий конкретную партию изделий, регион-получатель или заказчика, то впоследствии с учетом подобных признаков можно более гибко планировать производственную программу и контролировать ее выполнение в тех или иных разрезах.
Кроме того, объектная архитектура обеспечивает сквозную интеграцию всех производственных модулей Галактики с контурами управления финансами, логистикой, кадрами. Без подобной архитектуры интеграция новых модулей, версий и функций превращается в крайне сложную задачу.
Н. К.: Да, конечно. Я уже упоминал об особенностях планирования на нефтеперерабатывающих предприятиях, где для управления производственным циклом используется специализированное ПО. Для подобных случаев у нас предусмотрена возможность обмена данными в формате XML. Разумеется, в идеале взаимодействующие приложения должны поддерживать единую стандартную структуру XML-документов, но даже если пока этого нет, сделать адаптер, преобразующий одну XML-структуру в другую, гораздо легче, чем передавать сырые данные из одной системы в другую. Стандарт XML стал применяться в «Галактике» еще два года назад, но сейчас он реализован на уровне XML-интерфейса, которым снабжается каждый объект.
Н. К.: Она стала в полной мере соответствовать стандарту MRP-II. Планируется сбыт, производство и снабжение. Исходя из прогноза сбыта, имеющихся заказов и наличия товарных запасов формируется задание производственному подразделению. Затем рассчитываются потребности в материальных и производственных ресурсах и выдается задание на закупку необходимых материалов и комплектующих. Там, где это нужно, в дело включаются другие контуры «Галактики» (финансовый, логистический и т. д.).
Интересной особенностью является возможность составления нескольких альтернативных планов. Она полезна в тех случаях, когда предприятию приходится работать в условиях неопределенности: трудно прогнозировать спрос, цены подвержены значительным колебаниям, непредсказуемо меняется налоговая политика. Для каждого сценария развития событий предприятие может иметь свой план по номенклатуре и объемам. Дополнительная сложность здесь связана с необходимостью планирования перехода с одной альтернативной производственной программы на другую с учетом имеющихся ресурсов.
Н. К.: Думаю, следует упомянуть о совершенно новом контуре, обеспечивающем управление качеством выпускаемой продукции. Делается это на основе всей массы транзакционных документов, обрабатываемых системой в процессе изготовления изделия. В таких сопроводительных документах регистрируются конкретное оборудование и партии исходного сырья, работники, выполнявшие те или иные операции, а также любые другие реквизиты. Некоторые из них нередко отсутствуют в производственных или бухгалтерских документах, но из соображений контроля качества они могут быть туда добавлены.
Кроме того, теперь можно фиксировать показатели качества материальных ценностей, как закупаемых, так и продаваемых. Для этого к ним привязываются дополнительные свойства, учитываемые и контролируемые впоследствии на всех этапах. Подобный подход позволяет, например, всегда найти соответствие между конкретным изделием и качеством партии сырья, из которого оно было изготовлено. В результате появляется возможность снабжать произведенные товары паспортом качества, гарантирующим соответствие неким количественным нормам (процент жирности или содержание белка для пищевой продукции) или качественным показателям (экологическая чистота) каждой партии изделий. Если же какие-то важные показатели поступающего сырья варьируются от партии к партии, то это учитывается в нормах расхода для планируемых производственных операций (пересчет осуществляется автоматически по специальным таблицам).
В системе предусмотрены такие документы, как акты на брак, фиксирующие возврат бракованной продукции заказчиком, или внутренний брак, обнаруженный в процессе производства. Появляется возможность отслеживать причины, находить виновников, накапливать статистику и в конечном итоге принимать меры для целенаправленного повышения качества продукции.
Н. К.: Я уже говорил, что новая объектная архитектура как раз и призвана упростить настройку и подгонку системы к требованиям заказчика. Но, разумеется, определенную часть этого пути мы должны пройти вместе с ним. Особенно, когда речь идет о контурах планирования и управления производством. В отличие от, например, финансового или логистического модулей, где большая часть функций не зависит от специфики предприятия, настройка производственного контура всегда требует участия специалистов заказчика и консультантов «Галактики». Сегодня в нашем распоряжении около 120 высококвалифицированных специалистов по внедрению «Галактики»: половина из них трудится в центральном офисе, а остальные в региональных отделениях и у наших партнеров.
Н. К.: Среди них есть самые разные компании: одни занимаются только внедрением «Галактики», другие выполняют комплексные ИТ-проекты и сотрудничают с различными вендорами. Но все они прошли у нас обучение, получили необходимые сертификаты и приобрели практический опыт внедрения системы. Как правило, при работе с корпоративными клиентами в качестве генерального подрядчика выступаем мы сами, а роль субподрядчика выполняют партнеры. При этом руководит проектом один из вице-президентов «Галактики» и все нити управления сосредоточены в нашем центральном офисе.
Н. К.: Таковыми мы называем крупные предприятия или холдинги со сложной внутренней структурой, с большим количеством самостоятельных подразделений или компаний.
Если клиент не корпоративный, то партнер работает с ним самостоятельно. Тем не менее и в этом случае мы помогаем ему в заключении контракта и в организации продаж лицензий. Партнер получает свой процент от продажи лицензий и оплату за услуги по внедрению. При необходимости он может нанять на ограниченный период для решения очень сложных проблем нашего консультанта. Это выгоднее, чем держать в своей команде такого высокооплачиваемого специалиста все время. Точно также партнер имеет право сделать заказ на разработку дополнительной функциональности силами наших программистов. Техническую поддержку первого уровня осуществляет сам партнер, а если ему не удается решить какую-либо проблему, то подключаемся мы. Кроме того, партнер может обучить у нас своих специалистов как работе с системой «Галактика», так и методологии ее развертывания и внедрения.
Н. К.: На рынке она появится в конце сентября - как раз к выставке Softool'2002.
© 2001 ООО "Атлант-сервис" Пишите нам