Реализация проектного подхода к организации основной деятельности предприятия

Игорь Кочан (Ведущий аналитик компании «Топ Системы»)

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

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

Система T­FLEX DOCs 2010, предлагаемая российской компанией «Топ Системы», давно позиционируется  как инструментальное средство по управлению данными и организации взаимодействия пользователей в процессе проектирования и подготовки производства изделий. Однако немногие понимают, что именно под этим подразумевается. А суть в том, что T­FLEX DOCs 2010 обладает мощным открытым инструментарием, который позволяет довольно простым и понятным пользователю языком описать методику работы, которую избрало для себя то или иное предприятие. И в настоящей статье я постараюсь наглядно продемонстрировать, как реализовать проектный подход к работе на базе предлагаемых системой T­FLEX DOCs 2010 инструментов и интерфейсов. Иными словами, постараемся превратить мощную функциональность общего назначения в конкретную модель, направленную на решение реальных задач и учитывающую избранную нами методологию.

Начнем с основных понятий. И первое из них, конечно же, проект. Проектом может быть всё, что угодно. Это и проект разработки нового изделия, и проект модернизации или капитального ремонта, и проведение исследований. Ограничений нет. Есть лишь некоторые отличия в структуре данных, описывающих сущность понятия «проект». Кроме того, довольно часто в рамках одного и того же предприятия существуют проекты сразу нескольких типов, для каждого из которых имеются свои особенности выполнения. Тут как нельзя лучше нам подойдет функциональность системы T­FLEX DOCs 2010, позволяющая описать структуру данных, которые в дальнейшем будут использоваться в системе, именно в виде иерархии типов будущих объектов. Да­да, именно иерархии, так как система позволяет не просто описать свойства того или иного типа объекта, но и унаследовать свойства одного типа, чтобы породить новый, более конкретный тип данных.

Для решения поставленной задачи мы создадим новый справочник, который назовем «Рабочие проекты», и в нем построим простую иерархию типов, корнем которой будет проект, содержащий все общие свойства любого проекта, такие как наименование и обозначение, руководитель, дата создания и т.п., а наследниками — специализированные типы. Например, «Проект разработки нового изделия» и «Проект модернизации». Последний может отличаться тем, что будет иметь, к примеру, ссылку на ранее существовавший проект нового изделия, которое и подлежит модернизации. Можно не волноваться, если вы не уверены, все ли необходимые параметры типов заведены на этапе создания структуры. Система T­FLEX DOCs 2010 позволяет добавить их в любой момент. Теперь остается лишь «нарисовать» удобные диалоги свойств наших новых типов данных, расположив на них соответствующие параметры, и всё. Первый шаг сделан. Хотя нет, постойте… Задайте каждому типу свою иконку. Пусть структура проекта на экране пользователя выглядит не только умно и правильно, но еще и красиво. Помните, простота и наглядность — залог привлекательности любой программы.

Следующий шаг — структура самого проекта. Мне кажется довольно удачной мысль показать проект в виде дерева основных работ, которые предстоит выполнить для реализации данного проекта. Это как бы укрупненная структура этапов, степень детализации которых полностью зависти от вас. Для этого в том же самом справочнике мы заведем еще один тип — этап проекта. Оснастим его необходимым набором параметров, среди которых, конечно же, будут «Наименование этапа», «Ответственный», «Дата планового завершения» и т.п. Если настроить правила входимости так, что этап проекта может содержать в себе не только другие этапы, но и другие проекты, то у вас появится возможность создавать сложные иерархические проекты, которые, в свою очередь, состоят из более мелких. Хотя в большинстве случаев такие сложности ни к чему — можно ограничиться возможностью построить проект, в составе которого будет находиться обычное дерево этапов.

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

Следующий шаг — планирование и учет всех конкретных работ конкретных исполнителей. Наверное, вы уже обратили внимание на то, что в предыдущей части статьи мы вообще ничего не говорили о составе изделия, над которым идет работа, хотя наш проект подразумевает именно это. И вот теперь мы наконец­то подошли непосредственно к процессу работы — к выполнению проекта и сбору результатов. Для этих целей мы заведем еще один справочник, объекты которого будут представлять собой отдельные работы, выполняемые исполнителями в ходе реализации проекта. У данных объектов уже имеются не только параметры, отражающие суть работы, сроки ее выполнения и исполнителя, но и связи с любыми объектами системы, относящимися к данной работе. В первую очередь  это элементы структуры изделия, над которыми выполняются основные операции. Но это если говорить только о данных. Кроме них в системе T­FLEX DOCs 2010 имеется целый ряд инструментов, позволяющих не только работать с различными документами, но и полностью организовать процесс такой работы. Я говорю, конечно, о механизме бизнес­процессов. Разумеется, все предприятия работают по­своему, и бизнес­процессы обязательно должны отражать особенности сложившихся отношений и методов работы. Приведу пример, который представляется мне наиболее общим.

Итак, создадим в системе простой бизнес­процесс, который обеспечит следующую логику. Исполнитель, видя в списке активных работ новые, корректирует их параметры, устанавливая сроки предполагаемого завершения. Точнее, указывает предполагаемую длительность работы. При этом ему, для сведения, доступна информация о предполагаемой длительности, которую ввел руководитель при планировании работ. После этого работа, в которой уже указаны сроки ее выполнения, запускается по бизнес­процессу. Его первыми этапами являются процессы согласования сроков. Руководитель, получив соответствующее уведомление, может подтвердить плановые сроки или оспорить их, вернув работу исполнителю со своими комментариями. Этот цикл в общем бизнес­процессе может происходить неограниченное число раз до тех пор, пока сроки исполнения не будут согласованы или руководитель не примет волевое решение, оспорить которое исполнитель не в силах. На этом процесс согласования завершается. Далее, как это чаще всего бывает, исполнитель самостоятельно решает, какие работы и в каком порядке он будет выполнять, и запускает их по процессу выполнения по мере готовности. Процесс выполнения работ также довольно прост — у исполнителя появляется задание и связанная с ним работа. Исполнитель сам будет в дальнейшем классифицировать его как выполненное. В процессе исполнения задания исполнитель, а им может быть конструктор, технолог или любой другой специалист, участвующий в проекте, ведет работу по созданию и редактированию данных. В качестве данных могут выступать элементы структуры изделия, то есть сборки, узлы или отдельные детали конструкции, а также любые другие данные, находящиеся в хранилище T­FLEX DOCs 2010. Все результаты своей деятельности исполнитель связывает с одной из активных работ. В конечном счете, когда разработчик решает, что поставленная задача завершена, он отмечает работу как выполненную, уточняя реальные сроки ее исполнения (автоматическое вычисление сроков может использоваться лишь в качестве исходных данных, так как пользователь может параллельно вести несколько работ, при этом  лишь он сам знает долю своего участия в них). Информация о выполненной работе и реальных трудозатратах на нее автоматически попадает к руководителю, который должен ее подтвердить или вернуть задание на доработку. Если работа сделана корректно и документы, полученные в результате, успешно прошли процедуру согласования, то такая работа действительно объявляется завершенной и попадает в перечень выполненных работ проекта. Дальше она интересна нам лишь с точки зрения статистики, о которой мы еще поговорим.

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

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

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

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

Более того, система T­FLEX DOCs 2010 обладает мощной и очень развитой подсистемой управления проектами, которая позволяет отображать все вышеописанные работы и этапы проектов на диаграмме Ганта. Это не только упростит и сделает более наглядным восприятие структуры проекта, но и позволит использовать различные методы привязки планируемых работ друг к другу по срокам начала и завершения.

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

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

Вот теперь уже можно говорить, что в результате мы получаем реальную систему учета, которая действительно в состоянии отражать полный перечень выполняемых работ. К чему я клоню? Да к тому, что если в вашей системе имеется справочник с нормировочными коэффициентами всех выполняемых работ, то, связав его с работами, которые назначаются и реализуются исполнителями, мы получим все необходимые сведения о непосредственных затратах на данный проект. А  дальше, как говорится, дело техники — выгружаем эти данные в обменный файл и передаем его в любую учетную систему. И тут я хочу обратить внимание читателей на то, что система T­FLEX DOCs 2010, благодаря описанной здесь настройке, позволяет закрыть одну из самых серьезных брешей в любой системе управления и учета — связать фактически выполненные работы и разработанные документы со средствами учета затрат и рабочего времени, то есть положить в основание учетной системы точные и достоверные сведения.

Но давайте немного отвлечемся от пользы интеграции с экономической точки зрения и посмотрим на наши проекты под другим углом. Большинство видов деятельности завершаются тем, что предприятие производит продукцию, которая попадает к заказчику. Таким образом, жизненный цикл изделия не заканчивается его производством. Где и как зарегистрировать претензии, полученные от заказчика в процессе эксплуатации изделия? Где регистрировать работы по устранению недостатков, ремонтным мероприятиям и т.п.? Ответ прост — здесь же! Система T­FLEX DOCs 2010 предоставляет готовый набор структур данных и интерфейсов, которые позволят и регистрировать продажи, и хранить переписку, и контролировать все основные этапы жизненного цикла изделий. Для этого в составе системы T­FLEX DOCs 2010 имеются такие компоненты, как модуль работы с договорами, CRM­система, а также компоненты для регистрации и учета претензий и предложений заказчиков. Вы всегда можете воспользоваться ими для организации собственного единого информационного пространства или создать такие системы самостоятельно. Как видите, для этого не требуется ни умение программировать, ни наличие каких­то специальных инструментов. Всё это уже есть в системе T­FLEX DOCs 2010, поскольку это мощный и надежный инструмент, открытый и способствующий любым вашим начинаниям. 

САПР и графика 5`2011