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

Автор: Кочан И.Н.

В последнее время я читал множество статей о разнообразных возможностях различных системы. Это, безусловно, интересно, ибо разработчики прилагают массу усилий к тому, чтобы их программы «умели» как можно больше. Но в то же время, общаясь с представителями различных предприятий, мы всё чаще стали слышать один и тот же вопрос – как нам организовать внедрение? Какие задачи следует решить в первую очередь? На какую функциональность обратить наибольшее внимание, чтобы процесс внедрения был наиболее комплексным, быстрым и максимально эффективным? В конце концов, каких методов работы придерживаться в будущем? Иначе говоря, всё большему количеству пользователей сначала требуется решить методические вопросы, а уже потом вопросы технического характера. Ответам на некоторые из таких вопросов и будет посвящена эта статья.
Есть множество методов организации работы по проектированию новых изделий или выполнению заказов. И всё чаще и чаще мы стали встречать модель работы, которую условно можно назвать проектной. Вообще, работа «от проекта» одна из самых распространённых методик организации основного рабочего процесса на многих предприятиях. Поэтому сегодня мне и хотелось бы поговорить именно об этом.
Система 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, ибо это мощный и надёжный инструмент, открытый и способствующий любым вашим начинаниям.

Дополнительно