Стрелков П.В. (Pro|TECHNOLOGIES)
Планируемый цикл статей, посвященных проекту внедрения PLM на предприятиях ИГ УПЭК
Действующие лица:
- ПиЭм (Project Manager) – директор проекта от Pro|TECHNOLOGIES;
- ДиРектор – директор проекта от ИГ УПЭК;
- ЭКСперт – собирательный образ эксперта центра управления проектом УПЭК;
- ЗАМ – заместитель генерального директора предприятия по внедрению КСА;
- ИнженеР – инженер-внедренец из Pro|TECHNOLOGIES.
Предисловие
В этой статье мы хотим более подробно рассказать об одном из первых этапов проекта внедрения PLM на предприятиях Индустриальной группы “Украинская промышленноэнергетическая компания” (ИГ УПЭК). Речь пойдет о внедрении CAD/CAM/CAE-системы Pro/ ENGINEER и создании электронного архива в среде Windchill. В последующих статьях цикла мы планируем затронуть обсуждение таких вопросов, как внедрение систем ТПП, разработка постпроцессоров для станков с ЧПУ, реализация интеграции Windchill и системы 1С, которая используется на предприятиях индустриальной группы для управления производством. Кроме того, мы планируем отдельно познакомить вас с организацией процесса обучения и сертификации специалистов.
Конечно, весь материал можно было бы изложить сухим инженерным языком. Но подобных статей уже написано огромное количество, и читать еще одну, вам, уважаемые читатели, вряд ли было бы интересно. Поэтому автор решился на эксперимент и постарался превратить технический текст в небольшой классический рассказ. Ведь даже важную и серьезную информацию тоже можно преподносить с юмором. Насколько этот эксперимент окажется удачным – судить вам.
Итак, начнем…
Глава 1. Курс на Запад
Харьков. Тихий ноябрьский вечер.
В комнате переговоров центрального офиса ИГ УПЭК идет обсуждение организации внедрения Pro/ENGINEER.
– Подведем промежуточные итоги, – сказал ДиРектор. – Основная последовательность начальных шагов, в общем-то, понятна. Во-первых, мы должны подготовить учебные классы. Учитывая, что народу обучить мы должны много, классов нужно минимум три. А лучше четыре. Что делать с техническим обеспечением этих классов, тоже ясно: нужны компьютеры, сеть. Всё это мы подготовим в достаточно сжатые сроки. Ну а дальше что? На этом всё? Разве внедрение Pro/ENGINEER заканчивается обучением? Нас это явно не устраивает! Во-первых, наши сотрудники должны закрепить полученные знания, причем, в том числе и на реальных, практических задачах. Во-вторых, обязательно необходима аттестация. Теоретические знания и практические навыки по использованию Pro/ENGINEER должны быть оценены. Каждый специалист, прошедший обучение, должен получить оценку.
Собравшиеся переглянулись. На совещании, помимо ДиРектора и ЭКСперта, присутствовал ПиЭм, недавно приехавший в Харьков для решения возникших организационных вопросов. Он и взял слово.
– Давайте обратимся к опыту западных компаний в проведении масштабного обучения. И неважно, чему обучают: работе с программным обеспечением, новым методологиям или чемунибудь другому, – сказал ПиЭм. Он подошел к установленной в комнате доске и прикрепил к ней схему, иллюстрирующую типовой подход к организации процесса обучения.
Типовая схема организации обучения
– Первое, что мы должны обеспечить после завершения учебного курса, это возможность самостоятельного повторения пройденного материала, – продолжил ПиЭм, возвратившись к столу. – Постоянная практика является одним из важнейших элементов освоения программного продукта. Сотрудники, прошедшие обучение, должны выполнить несколько реальных контрольных заданий по изделиям, которые производятся на их предприятиях. Естественно, при выполнении контрольных заданий ваши сотрудники могут обращаться к нам за консультациями.
– А кто должен подготовить и выдать контрольные задания? – уточнил ЭКСперт. – Мы же не сможем сделать это без участия представителей предприятий.
– Считаю, что эта работа должна быть выполнена совместно ЭКСпертом и представителями предприятий, сотрудниками, которые будут проходить обучение, – поставил точку в этом вопросе ДиРектор. – Пока что всё, о чём говорилось, звучит очень логично, и я поддерживаю такой подход.
ПиЭм снова встал из-за стола, подошел к нарисованной на доске схеме и продолжил:
– После того, как контрольные задания выполнены, должен быть проведен экзамен.
– Совершенно верно! При этом критерии оценки знаний должны быть формальными. Вопрос этот очень серьезный, и на него не должен влиять субъективизм ваших преподавателей, – отметил ДиРектор.
– Итак, по результатам экзаменов каждый сотрудник предприятия, который прошел обучение, получит сводную оценку, – продолжил ПиЭм. – Далее мы должны сразу же перейти к выполнению пилотных проектов, которые позволят применить полученные знания в реальной работе.
– Стоп! С этого места, пожалуйста, поподробнее, – попросил ЭКСперт. – Когда и как мы будем выполнять пилотные проекты, если у специалистов и так не хватает времени на выполнение своей непосредственной работы?
ЭКСперт хорошо понимал, что именно ему придется реализовывать всё то, что сейчас планируется. Зная, с чем на практике столкнется внедрение на заводах, он был заинтересован рассмотреть все возможные риски максимально полно.
Было понятно, что обсуждение подошло к одному из наиболее болезненных вопросов. Пока речь идет о проведении обучения, проблем меньше всего. Пусть и “со скрипом”, но сотрудников можно выдернуть на несколько дней из рабочего процесса. Но вот пилотные проекты… Это же совсем другое дело. Пилотные проекты предполагают работу над реальным изделием, пусть даже и разработанным ранее.
– Да, с загрузкой специалистов, очевидно, будет много вопросов. Но никто и никогда не утверждал, что будет иначе! Ясно, что внедрение требует дополнительных усилий со стороны специалистов предприятия, – сказал ПиЭм.
– Необходима мотивация, – ДиРектор сформулировал одно из важнейших организационных решений в рамках проекта. – Надо сделать так, чтобы сотрудникам было выгодно участвовать в пилотных проектах. Этот вопрос мы должны согласовать с высшим руководством и владельцами УПЭК. Но в условиях кризиса, думаю, мотивация может быть только одна – сохранение своего рабочего места. Я обязательно переговорю завтра об этом с владельцами, и мы примем соответствующее решение.
– Последнее, что я хотел бы отметить, это необходимость тщательно составить расписание и контролировать выполнение Типовая схема организации обучения работ. Предстоит обучить много специалистов. Фактически, нам необходимо прямо здесь, в УПЭК, организовать свой миниВУЗ. И если мы не будем очень аккуратно управлять этим процессом, ничего хорошего не выйдет, – подвел черту ПиЭм.
Совещание длилось уже больше трех часов. ДиРектор подошел к окну. Было уже совсем темно...– На этом всё! – сказал он. – Даю старт!
С этого момента проект вступил в новую фазу. Подготовка и обсуждения закончились, начинались реальные работы и реальные трудности. Всё закрутилось...
Глава 2. Жизнь вносит свои коррективы
Вырезка из газеты “Наш УПЭК”, №35 от 05.12.2008
Сразу по возвращении из Харькова ПиЭм занялся составлением детального расписания учебных курсов. Задача была откровенно непростая. Необходимо было расписать более 3000 учебных часов 43-х различных видов учебных курсов в четырех учебных классах. Да где еще найти преподавателей на такой объем работ?!
Тем не менее, расписание было составлено, согласовано с ЭКСпертом и утверждено ДиРектором. Казалось, что все проблемы решены.
И вот, наступило 17 ноября 2008 года. Первое занятие “Введение в Pro/ENGINEER” состоялось вћвремя. Казалось, что дальше всё должно пойти как по маслу. Учебные классы готовы принять слушателей. Преподаватели выделены и проинформированы о своей загрузке. Логистика проработана. Что еще надо для “счастья”? Ничего…
Как бы ни так! Рабочий день уже подходил к концу, когда в офисе Pro|TECHNOLOGIES раздался телефонный звонок:
– Это звонит ЭКСперт, УПЭК, Харьков. Я могу переговорить с ПиЭм?
– Я Вас слушаю, – сказал ПиЭм.
– У нас возникли непредвиденные сложности. Большая часть сотрудников – слушателей группы, которая была сформирована для прохождения курса “Конструирование тонколистовых деталей”, на следующей неделе участвует в выставке. На обучение они прийти никак не смогут. Надо что-то делать. Мы можем перенести этот курс на более поздний срок?
– Вопрос не так прост, – задумался ПиЭм. – Во-первых, обучение у нас спланировано достаточно плотно, и свободных учебных классов может просто не оказаться. Во-вторых, необходимо уточнить загрузку преподавателя, который будет читать этот курс. Возможно, у него запланированы другие работы. Давайте я возьму тайм-аут до утра, чтобы подумать и предложить решение.
– Хорошо, договорились. До свидания! – ЭКСперт повесил трубку.
Необходимо было срочно искать какое-то решение. ПиЭм открыл учебное расписание и стал “колдовать” над ним, меняя порядок курсов, выискивая свободные места в загрузке классов, перераспределяя преподавателей между курсами. В результате решение было найдено.
С утра ПиЭм позвонил ЭКСперту.
– Предлагаю заменить курс по “Конструированию тонколистовых деталей” на курс “Подготовка КД в Pro/ENGINEER” для другой группы. Преподаватель – один и тот же. Этот курс длиннее на один день, но в это время класс у нас свободен.
– Думаю, такой вариант нас устроит, – ответил ЭКСперт. – Я уточню на заводе и дам Вам ответ сегодня в течение дня.
– Отлично! Договорились.
Проблема была решена, но как оказалось, это было только начало. За всё время проведения обучения (свыше 300 дней) с подобными вопросами пришлось сталкиваться не раз. И, как позже выяснилось, эти вопросы были не самыми сложными.
В один из очередных приездов ПиЭм в Харьков потребовалось провести совещание для решения организационных вопросов не в центральном офисе УПЭК, а непосредственно на одном из предприятий. После совещания ПиЭм попросил отвести его к конструкторам, которые, как он знал, совсем недавно прослушали базовые курсы по работе с Pro/ENGINEER и в данное время должны были выполнять практические задания.
– Добрый день, уважаемые коллеги, – поздоровался ПиЭм.
– Здравствуйте! – ответили пользователи, выглянув из-за кульманов.
– А где компьютеры? Где Pro/ENGINEER? – удивился ПиЭм, обращаясь к ЭКСперту, который был с ним.
– Ну… тут такое дело… В общем, компьютеры для этой группы поставить пока не успели. Их только вчера привезли. Надо же еще программы установить, – смутился ЭКСперт.
– Вот это да! А как же самостоятельная подготовка? Ведь без нее через пару недель все забудут о том, что изучалось на курсах!
ПиЭм понял, что этот вопрос надо решать немедленно. Задержавшись еще на один день в Харькове, он обсудил возникшую проблему с ДиРектором. Было решено составить детальный график поставки вычислительной техники и её установки на рабочих местах, согласованный с графиком обучения.
После этого критичных проблем с обеспечением вычислительной техникой практически не было, хотя, конечно же, отдельные вопросы периодически возникали.
Учебные курсы шли свои чередом, и вот уже большинство пользователей прошло базовое обучение. Настало время переходить к реализации пилотных проектов.
Первые этапы пилотных проектов прошли без особых затруднений. Обучение было проведено качественно. Система мотивации работала. Пользователи с успехом создавали свои первые реальные модели. Вопросы стали возникать, когда дело дошло до оформления чертежей.
– У нас проблемы! – сказал ЭКСперт на очередной встрече с ПиЭм. – Почему-то пользователи тратят на оформление чертежей очень много времени. И все жалуются, что это не работа, а какое-то мучение. Это нонсенс – тратить столько времени на оформление простейшего чертежа.
– Странно. Быть такого не может. Давайте поговорим с пользователями, выясним, в чем проблема, – ответил ПиЭм.
В ходе разговора выяснилось, что на рабочих местах был установлен Pro/ENGINEER в такой конфигурации, которая имела лишь минимальные настройки под ЕСКД. Необходимо было срочно устанавливать комплект настроек, автоматизирующий оформление чертежей по ЕСКД. Более того, пришлось дорабатывать эти настройки в соответствии с требованиями УПЭК, так как отдельные моменты в стандартном комплекте настроек не были учтены.
Работа по этому направлению проходила довольно болезненно. Слишком много нюансов требовалось предусмотреть. Тем не менее, в конце концов, инженеры Pro|TECHNOLOGIES разработали комплект настроек Pro/ENGINEER под ЕСКД, который отвечал практически всем требованиям пользователей УПЭК. После этого оформление чертежей по ЕСКД ни у кого уже не вызывало затруднений и занимало минимум времени.
В один из мартовских дней 2009 г. ПиЭм позвонил ДиРектору, чтобы узнать последние новости “с фронтов”.
– Совсем недавно я узнал, что один из наших заводов, ЛКМЗ, получил новый заказ, который было решено полностью выполнить в Pro/ENGINEER, – сказал ДиРектор. – У меня есть некоторые опасения. Не рано ли на заводе приняли решение о запуске системы фактически в промышленную эксплуатацию? Что Вы думаете на этот счет?
– К этому вопросу надо подойти очень аккуратно, – согласился ПиЭм. – Если заказ срочный и ответственный, то ориентация на использование новой системы может повредить. У людей еще недостаточно практики, а руководство будет требовать максимально быстрого выполнения работ. Еще нет наработанной базы.
Что ж, насколько я понимаю, наши мнения по этому вопросу совпадают.
Тем не менее, на предприятии было принято решение вести новую разработку полностью в среде Pro/ENGINEER. Однако, как известно, лучшее – враг хорошего. Реализовать первый проект полностью в Pro/ENGINEER не получилось. Конечно же, сказались те факторы, о которых говорили ДиРектор и ПиЭм. Но основной причиной стало то, что руководители среднего звена отнеслись к проекту формально. Постановка задачи в их устах звучала так: “Мне неважно, как и чем вы будете рисовать. Для меня главное – сдать чертеж в архив максимально быстро. А что там дальше будет у технологов, у конструкторов оснастки, в производстве – меня не волнует. Я же за это не отвечаю. Так что, делайте, что хотите”. Такая ситуация была хоть и прогнозируема, но в таких резких формах мало кем ожидалась.
После защиты очередного этапа, в кабинете ДиРектора речь зашла об этой проблеме.
– Да... Честно говоря, мы не ожидали, что получится именно так, – ДиРектор был явно расстроен.
ПиЭм тоже не ожидал, что сопротивление примет такой откровенный характер.
– У этой проблемы много составляющих, – задумчиво сказал он. – Не буду повторяться, поскольку часть вопросов мы с Вами уже обсуждали, когда впервые зашла речь о реализации новой разработки полностью в Pro/ENGINEER. Однако хотел бы еще отметить вот какой момент. О том, что часть работ ведется по старинке, мы узнали только постфактум. То есть, нам явно не хватало возможности постоянного мониторинга ситуации. Мы не видели, какая документация выпускается, при помощи каких средств и в какие сроки. Нам необходим регулярный простой мониторинг, контроль над процессом разработки. Вот в этом нам и поможет следующий этап нашего проекта – запуск Windchill.
Первые проекты в Pro/ENGINEER
Глава 3. Время пришло
Время шло, Pro/ENGINEER постепенно входил в привычный распорядок жизни инженеров. По мере роста их опыта уходили те проблемы, которые раньше казались трудноразрешимыми (привычка сотрудников работать за кульманом, сложности оформления по стандартам ЕСКД ассоциативных чертежей, связанных с 3D-моделями, необходимость применения специализированных модулей Pro/ENGINEER, а не только базового функционала). С другой стороны, возникали новые вопросы. Объемы и количество создаваемых моделей и чертежей росли. Разработчикам стало достаточно проблематично разбираться даже в своих файлах, не говоря уж о том, чтобы найти что-то на компьютере соседа. Как-то постепенно, постепенно, а потом и остро, встала проблема взаимодействия разработчиков – в том числе, с разных, территориально удаленных предприятий индустриальной группы. В среде руководителей стало складываться мнение, что как-то глупо создавать электронные документы и при этом продолжать согласовывать бумажные. Сотрудники службы безопасности предприятий вдруг поняли, что электронная модель и чертеж, это ведь не бумага, и вынести информацию за проходную не составляет труда.
В одну из пятниц в конце рабочего дня ПиЭм, как и обычно, на протяжении последних шести месяцев, просматривал календарный план и уточнял список оперативных задач на следующую неделю.
– Ого! Как быстро летит время, – подумал ПиЭм. – Вроде совсем недавно работали по пилотным проектам Pro/ENGINEER, а уже пора начинать внедрение электронного архива. Так… На следующую неделю надо планировать поездку в Харьков. Пора проводить организационное совещание по этому вопросу.
Для выступления нужно было подготовить материалы. ПиЭм набросал план презентации.
– Какие вопросы необходимо озвучить на совещании? – рассуждал он. – Обязательно надо отразить место и роль подпроектов по Windchill в общем проекте КСА. Это первое. Далее следует подробно рассказать о том, как будут организованы работы. Да, кстати, надо четко обозначить роли и ответственность. В завершение – представить детальный план работ по направлению “электронный архив”. Вроде всё. Нет… кажется, что-то упустил, причем что-то очень важное.
ПиЭм взял лист бумаги и нарисовал большой знак вопроса. Ему необходимо было пообщаться с ДиРектором.
– Добрый вечер! – Поздоровался ПиЭм. – Прошу Вашей помощи в решении вот какого вопроса…
ПиЭм вкратце обрисовал структуру презентации, над которой работал, и озвучил свои сомнения, что в демонстрации недостает чего-то главного.
– А зачем нужен электронный архив? – Вопрос ДиРектора был риторическим. – Если с самого начала не донести до участников работ необходимость и важность внедрения электронного архива, да так, чтобы ни у кого даже мысли не возникло, что можно обойтись без него, то все остальные вопросы можно даже и не рассматривать. ПиЭм написал под знаком вопроса: “Зачем нужен электронный архив”. Дальше пункты стали появляться один за другим.
В завершение разговора ПиЭм и ДиРектор со- гласовали дату совещания.
Глава 4. Дежавю
– Где-то мы такое уже проходили, – думал ДиРектор, рассматривая расписание работ на следующую неделю. – Неужели опять организационный этап? Зачем? Ведь всё уже столько раз обсуждалось. Хотя – стоп! Когда мы начинали работать с Pro/ENGINEER, план-то давно уже был разработан. Тем не менее, в процессе работ мы так намучались с выверкой сроков и дополнительными согласованиями. Да... В начале любого этапа организационные работы необходимы.
Организация работ по внедрению электронного архива имела классическую структуру. В основе всего лежал технический проект автоматизации – документ, описывающий бизнес-процессы, которые должны быть автоматизированы, и основные требования к автоматизации. Фактически, этот документ давал ответ на вопрос, что должно быть реализовано.
Следующий блок работ можно было назвать собственно реализацией. На протяжении достаточно короткого промежутка времени предстояло выполнить настройку системы (естественно, вначале прописав всё на уровне документа “техническая спецификация”), разработать ролевые инструкции (четкие, понятные указания пользователям о том, как и в каких случаях применять систему) и провести тестирование по отработанной уже технологии пилотных проектов.
Далее, после того как решение уже примет законченные формы, необходимо провести массовое обучение пользователей (более 300 человек) по ролевым инструкциям и начать его опытную эксплуатацию. При этом режим опытной эксплуатации предполагает, во-первых, активное сопровождение со стороны Pro|TECHNOLOGIES, во-вторых, строгое планирование и контроль отработки функционала со стороны УПЭК. После успешного завершения опытной эксплуатации, должно быть принято решение о передаче системы в промышленную эксплуатацию и решение о штатном применении электронного архива.
Схема организации работ по внедрению электронного архива
Несмотря на всю кажущуюся простоту и логичность предложенной схемы, организационное совещание прошло достаточно напряженно. После завершения доклада ПиЭм, слово взял ДиРектор.
– Не знаю, как коллегам, но лично мне не совсем понятно, кто те люди, которые будут проводить тестирование. С Pro/ENGINEER всё было ясно: вот инструмент, вот конструкторы и технологи, для которых этот инструмент предназначен. Выбираем из них наиболее продвинутых, и вперед! С Windchill же ситуация иная. Здесь мы рассматриваем бизнес-процессы, в которых задействовано множество специалистов самых разных направлений. Как быть в этом случае? – спросил он.
Понимая всю важность вопроса ДиРектора, ПиЭм сразу же дал ответ:
– В случае с Windchill, нам необходимо сформировать рабочую группу, в составе которой будут представители всех основных ролей, которые задействованы в процессах. Именно ролей, а не служб. Например, рассмотрим процесс согласования и утверждения. В данном процессе у нас задействованы две основные роли: согласующие и утверждающие. Понятно, что если мы говорим, например, о чертежах, то в качестве согласующих лиц реально будут выступать ведущие конструкторы, технологи, представители нормоконтроля, а в качестве утверждающего, как правило, главный конструктор. Однако, действия, выполняемые в системе Windchill всеми этими специалистами, будут практически одинаковыми. Надо получить документ, открыть и просмотреть его, внести замечания, а если мы говорим об утверждающих, принять решение об утверждении или отклонении документа. Поскольку действия одинаковы, то нет смысла привлекать к тестированию всех этих специалистов. Достаточно привлечь кого-то одного, кто выполнит проверку всех этих типовых действий. Аналогичный подход необходимо применить и к остальным процессам. В результате команда ключевых пользователей будет не такой уж большой.
– Спасибо, ответ понятен, – ДиРектор понял, что этот вопрос проработан и вполне решаем.
ЭКСперта, в свою очередь, заинтересовали другие моменты:
– А что будет с теми наработками в Pro/ENGINEER, которые у нас уже есть сейчас? Файлы- то хранятся на локальных компьютерах, а не в электронном архиве.
– Во-первых, часть из этих наработок будет загружена в ходе тестирования, а еще часть, причем достаточно значительная, в ходе опытной эксплуатации, – ответил ПиЭм. – В дальнейшем же у нас не будет иного выхода, как провести ревизию всего того, что уже создано на локальных рабочих местах, и составить график загрузки этих чертежей и моделей, но уже в рамках промышленной эксплуатации. Понятно, что это определенная дополнительная работа, но иного выбора у нас нет, да и не было. Вспомните, как проходило внедрение Pro/ENGINEER. Если бы одновременно с этим мы вели и работы по электронному архиву, то у нас бы просто ничего не получилось. Люди бы не выдержали такого объема новых технологий, внедряемых одновременно.
– Есть еще один момент, который нас сильно беспокоит, – взял слово ЗАМ. – А что если в техническом проекте мы в чём-то ошиблись, что-то не предусмотрели? Всё-таки это документ, а не “живая” система. А с документом всякое может быть.
– Спасибо за вопрос! Момент действительно очень важный, – сказал ПиЭм. – Вы абсолютно правы, предусмотреть сразу всё в документе нереально. Для решения этого вопроса нами предусмотрен итерационный процесс разработки. Это означает, что вы не столкнетесь с такой ситуацией, когда по истечении срока реализации будет представлен законченный продукт, который не удовлетворяет вашим требованиям. В самом процессе разработки мы планируем несколько раз проводить промежуточные демонстрации и тестирования, по мере реализации отдельных законченных функциональных блоков. По результатам таких промежуточных демонстраций мы и будем принимать решения о необходимости внесения изменений – как в технический проект, так и в систему. Кроме этого, если Вы обратили внимание, в плане работ параллельно с тестированием заложена доработка решения. Всё это позволит нам двигаться постепенно и выйти на опытную эксплуатацию именно с тем решением, которое максимально соответствует вашим потребностям.
Совещание закончилось лишь после того, как были обсуждены все основные вопросы. Итак, детальный график внедрения электронного архива был согласован и утвержден. Необходимо было приступать к реальной работе.
Глава 5. И снова в бой
Первый рабочий вопрос, который следовало решить, касался развертывания технической инфраструктуры. Да, уже были оснащены рабочие классы, на рабочих местах пользователей установлены компьютеры. Но для электронного архива требовались серверa. Не один сервер, а именно серверa, поскольку надо было создать единый архив для группы территориально удаленных предприятий. А в этом случае использование одного централизованного сeрвера неэффективно, так как необходимость передачи CAD-данных создает существенную нагрузку на сеть, что приводит к снижению общей производительности системы. Архив должен быть единым и централизованным, а серверов – несколько? Парадокс!
ИнженеР и ЭКСперт обсуждали архитектуру решения.
– Мы будем использовать механизм, называемый репликация, – рассказывал ИнженеР. – Одна из особенностей системы Windchill заключается в том, что мы можем организовать архив таким образом, чтобы файлы (представляющие собой CAD-модели и чертежи), хранились на разных серверах, но сам архив при этом, с точки зрения пользователя, выглядел как единое хранилище. То есть, система автоматически будет переадресовывать запросы пользователей на нужный сервер. В результате, запросив доступ к документу в центральном архиве, пользователь физически получит файл с ближайшего к нему сервера. Тем самым мы обеспечим оптимальную загрузку сети, а, следовательно, и наилучшую производительность.
ИнженеР взял лист бумаги и набросал схему организации инфраструктуры электронного архива. На основе этой схемы и велась дальнейшая работа.
Установив и протестировав работоспособность всех компонентов системы, команда проекта перешла к решению очередных запланированных задач.
После формирования группы внедрения в соответствии с принципами, которые были заложены на организационном этапе, было проведено обучение использованию стандартного функционала системы Windchill. Отдельно учились системные и бизнес-администраторы (специалисты УПЭК, ответственные как за сопровождение системных компонентов Windchill, так и за настройку бизнес-логики решения).
Структура электронного архива
Параллельно с этим, инженеры Pro|TECHNOLOGIES занимались настройками системы: создавали учетные записи для всех пользователей, группы, роли, указывали права доступа, создавали новые типы информационных объектов, шаблоны жизненных циклов и рабочие потоки, а также автоматизировали формирование отчетов.
Второй задачей было подготовить документацию – ролевые инструкции, которые детально описывали последовательность действий каждого пользователя, в соответствии с его ролью для выполнения каждой задачи бизнес-процесса.
Работа кипела, и в результате, точно в соответствии с планом, всё было готово к тестированию.
Когда до этого этапа, согласно рабочему плану, еще оставалось две недели, ПиЭм решил позвонить ДиРектору, чтобы обсудить организацию процесса тестирования.
– Для реального выполнения этой задачи требуется детализация. Нам необходимо четко сформулировать постановку задачи для наших специалистов по проведению тестирования, – сразу после того, как вопрос был озвучен, сказал ДиРектор.
– Я с Вами полностью согласен. Учитывая объем произведенных настроек и количество вовлеченных специалистов, просто передать настроенное решение явно будет недостаточно. Подготовительные мероприятия надо начинать уже сейчас, – согласился ПиЭм. – У меня есть ряд предложений. Нам надо составить детальный график. Тестирование должно проводиться по каждому бизнес-процессу, каждой отдельной задаче. Необходимо закрепить ответственных за проверку каждого отдельного этапа бизнес-процесса, и определить сроки, в которые тестирование должно быть проведено.
– Да, хорошо, – сказал ДиРектор. – А по результатам тестирования группа, которая его проводила, должна составить отчет, в котором должно быть указано, как и что проверялось, какие ошибки найдены, дано общее заключение о возможности использования системы. Для этого я назначу в группе старшего по этой задаче. Скорее всего, это будет ЭКСперт.
– Отлично! Если Вы не возражаете, я пришлю Вам на утверждение график тестирования, который мы обсудили.
В ходе тестирования были выявлены недочеты и сделан ряд замечаний, которые относились как к настройкам системы, так и к ролевым инструкциям. Недоработки были оперативно устранены, и настало время передавать решение в опытную эксплуатацию.
Фрагмент графика тестирования
Но перед этим необходимо было обучить всех пользователей. Это обучение существенным образом отличается от тренингов, которые проходила группа тестирования. Рядовым пользователям не нужен весь объем функционала системы. Им важно другое: четко представлять, какую последовательность действий надо выполнить, чтобы решить конкретную задачу бизнес-процесса. Именно поэтому обучение пользователей проводилось не на базе стандартных курсов по функционалу Windchill, а на основе ролевых инструкций.
Учитывая количество сотрудников, которых предстояло обучить, пришлось, как и в случае с Pro/ENGINEER, параллельно задействовать четыре учебных класса. Все специалисты были распределены по группам. В рамках тренингов соответствующие группы обучались использованию системы только в тех бизнес-процессах, участниками которых они являлись.
По мере того, как завершалось обучение пользователей, начинались работы в рамках опытной эксплуатации. Схема организации работ аналогична тестированию. Единственное отличие, это масштаб (в опытной эксплуатации участвуют практически все пользователи) и контрольные данные (изделия пилотных проектов). Остальные принципы остаются неизменными. Тщательно проводится распределение работ (задачи бизнес-процессов) между участниками опытной эксплуатации. Работы идут под контролем экспертов центра управления проектом. По результатам оформляются отчеты: какие бизнеспроцессы отработаны, какие задачи и кем выполнены, какие есть замечания, а также заключение о возможности передачи решения в промышленную эксплуатацию.
После завершения опытной эксплуатации и устранения последних недочетов (куда же без них!) было принято решение о передаче электронного архива и Pro/ENGINEER в промышленную эксплуатацию.
Глава 6. Взгляд в будущее
Прошло два месяца после ввода Pro/ENGINEER и электронного архива на базе Windchill в промышленную эксплуатацию. Отшумели жаркие споры. “Притерлись” люди и программы.
Известно, что первые месяцы промышленной эксплуатации являются самыми ответственными. Именно этот период определяет, будет ли решение жить и успешно развиваться, или о нём через некоторое время (как только ослабнет контроль руководства, а это непременно случится) забудут. Поэтому первое подведение итогов промышленной эксплуатации и анализ результатов были запланированы не через год, не через полгода, а всего через пару месяцев штатной работы системы.
Учитывая то, что действующий электронный архив – это не просто средство хранения документации, а еще и инструмент автоматизации бизнес-процессов, вопрос о том, как собирать данные для контроля эксплуатации, не стоял. Конечно же, для этого надо использовать возможности Windchill.
ЭКСперт самостоятельно (благо опыта настройки Windchill уже было достаточно), буквально за полдня подготовил несколько автоматических отчетов, демонстрирующих динамику использования системы. Отчеты были отправлены руководству УПЭК и в Pro|TECHNOLOGIES.
– Интересно, – ДиРектор только взглянул на полученные отчеты, и у него сразу стали возникать вопросы. – Мы обучили порядка 300 человек, а на графике максимальное количество пользователей в день чуть превышает отметку 120…
– Всё логично, – сказал ЭКСперт. Он детально проанализировал отчеты, которые подготовил, и был готов дать ответы на любые вопросы. – На графике показано количество уникальных пользователей, которые работали с системой в течение дня. При этом, например, Петров с системой работал в понедельник и среду, а Иванов – во вторник и четверг. Если же посмотреть, сколько всего уникальных пользователей работало с системой в течение месяца, то цифра будет как раз порядка 300.
– Второй график более интересен, – ДиРектор продолжил изучать представленные отчеты. – Раньше получить подобную информацию было либо очень сложно, либо практически невозможно. А сейчас мы имеем возможность оценить интенсивность работы наших конструкторов. Можно ли сделать такой же отчет, но в разбивке по предприятиям? И сколько времени займет актуализация этих данных, например, по состоянию на следующий месяц?
– Актуализация данных займет секунды. Ведь это – автоматический отчет, разработанный мною, – не без гордости сказал ЭКСперт. – Что же касается отчета в разбивке по предприятиям, я без проблем сделаю его за несколько часов. Сегодня же пришлю Вам этот документ.
Изучать сводные данные ДиРектору, безусловно, было интересно. Ведь получать подобную информацию – да еще в считанные секунды, да из беспристрастного источника – мечта любого руководителя. И он продолжил “допрос” ЭКСперта.
– Всё это, конечно, хорошо. Только вот, начиная проект, мы обещали руководству существенное сокращение сроков. Есть ли у Вас информация, например, о длительности процедуры согласования и утверждения конструкторской документации?
– Конечно же есть, – ЭКСперт ожидал этот вопрос. – Так как согласование и утверждение КД сейчас выполняется в среде Windchill, мы имеем полную картину по срокам, участникам, и другую детальную информацию. Как человек, давно работающий на предприятиях УПЭК, в том числе в конструкторских отделах, могу сказать, что раньше согласование КД занимало три-пять дней. Более точной информации нет – кто ж её собирал… Сейчас, в Windchill мы проводим утверждение менее чем за один час. При этом я говорю о реальной работе, а не о каких-то тестовых прогонах. Даже согласование документации между несколькими смежными предприятиями, которое раньше длилось чуть ли не полмесяца, сейчас проходит максимум за 4 дня.
– Вот это уже показатель! Вот это уже результат! – ДиРектор был доволен, что система начала давать реальные, осязаемые результаты, практически сразу же после начала штатной эксплуатации. – Применение продуктов PTC действительно дает возможность ускорить разработку новой продукции и вывод её на рынок, снизить стоимость разработки и изготовления, повысить технический уровень и качество изделий, уменьшить их материалоемкость, увеличить эффективность. Теперь ясно видно, что всё так и есть!
Двухмесячная статистика использования Windchill
Второй месяц эксплуатации. Статистика ежедневного использования Pro/ENGINEER
Продолжение истории вы узнаете в следующих статьях цикла, посвященного проекту внедрения PLM на предприятиях ИГ УПЭК.
