The Web-site of design Company Chelyabenergoproekt in English   English
Проектные работы в проектной организации Челябэнергопроект Заказать проектные работы в письме к проектной организации Челябэнергопроект Карта сайта
Die Web-seite der Projektorganisation Tscheljabenergoprojekt in Deutsch   Deutsch




Création de site web société française Chelyabenergoproekt   Française

   Облако тегов на сайте проектной организации Челябэнергопроект
Проекты интеллектуального мастерства!
новости компании
30.12.2015 С Новым годом!
Администрация ...
21.12.2015 С Днём Энергетика!
Уважаемые друзья и коллеги! Поздравляю вас с нашим большим праздником – Днем Энергетика! ...



новости отрасли
объекты Ростехнадзора
  Облако тегов
проектирование монтаж ключ котел кран сертификат ГОСТ ремонт заказЧелябинск

Концепция единого информационного пространства проектной организации
Сегодня стали общим местом рассуждения о постоянно растущем значении ИТ-услуг в экономике организаций, и, в частности, компаний, выполняющих проектные работы и «проекты под ключ», и, соответственно, о возрастающей ценности автоматизации деятельности в области предоставления этих (проектных) услуг. Тем не менее, если посмотреть на проблему глазами обычного ИТ-менеджера, с хорошими инструментами здесь непросто. Функции ИТ-службы, в автоматизации которых наш менеджер может быть заинтересован, многообразны. Это, в традиционных терминах, и бизнес-моделирование, и управление проектами (в основном, проектами разработки и/или внедрения приложений), и управление требованиями пользователей, и бюджетирование, и кое-то еще. Возникает желание снять с полки некий программный продукт, охватывающий все эти функции в единой информационной среде, поскольку интуитивно понятно, что функции тесно взаимосвязаны и имеют много общих информационных объектов. Эксперты информированы о линейке IBM Rational. Это действительно концептуально (и во многом программно) целостный многофункциональный инструментарий, охватывающий практически все перечисленные выше разделы, хотя и с явным уклоном в управление разработкой новых продуктов, что для большинства ИТ-служб не столь актуально. Но стоит дорого, внедряется непросто. Конечно, для 98% Top500, где он, по данным IBM, используется, это, видимо, не проблема. Но для тех организаций, выполняющих проектные работы, где стоимость его покупки может превысить весь годовой ИТ-бюджет, IBM Rational решением не является.

Конечно, существуют развитые инструменты по отдельным функциональным разделам. Например, для бизнес-моделирования – ARIS, BPwin, AnyLogic (среда имитационного моделирования – разработка российской компании), та же Rational Rose, для управления проектами – Open Plan, Primavera, Microsoft Project, NauDoc (бесплатная базовая комплектация с открытым кодом), для управления требованиями – Hewlett-Packard Open View. Но, во-первых, инструменты тоже, по большей части, дорогостоящие, во-вторых, разрозненные, информационно между собой не связанные, целостный процесс сами по себе не организующие. И в третьих – что особенно относится к инструментам бизнес-моделирования – мало практичные, особенно, в отличие от западных компаний, для российских компаний. Хотя тот же ARIS позиционируется и как инструмент визуализации, и как исходный материал для автоматизации, но его на практике так не используют. Да и трудоемкость описания объекта здесь такая, что это описание для работающего бизнеса заведомо утрачивает актуальность задолго до того, как будет составлено.

Выходом является сборка из модулей перечисленных инструментов на базе связующего Microsoft Excel.

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

Рассмотрим концепцию автоматизации ИТ-службы на принципах единого информационного пространства (ЕИП) – аналогично ERP для проектной организации в целом, – причем концепцию, базирующуюся на достаточно простых практических посылках.

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

Сформулируем основные моменты политики организации, осуществляющей проектно-изыскательские работы:
- Этапность. Действительно, система автоматизированных технологий проектирования строится последовательными очередями. Постепенно наращивается и заменяется вычислительная техника, приобретается и обновляется программное обеспечение, формируется информационное и методическое обеспечение. Накапливается геоинформационный фонд районов, где проводилось проектирование и реконструкция соответствующих объектов. Этапность обеспечивает освоение проектировщиками средств и методов работы на персональных компьютерах параллельно с развитием вычислительных средств и созданием информационного обеспечения.
- Централизация. Действительно, в основе построения необходимо заложить принцип централизованного хранения и распределенной обработки информации. На базе объемных носителей данных и мощных серверов необходимо создать единое хранилище проектно-сметной документации, высокоскоростную локальную сеть для интенсивный обмен документами между проектировщиками, с обязательным хранением на серверах (включая хранение версий документов). Это позволяет проводить единую информационную политику и строить управление пространственной и атрибутивной информацией.
- Концентрация дорогостоящей периферии и расходных материалов. Действительно, печать и тиражирование цветных, полноформатных спецтопопланов и растровых карт требует больших затрат. Для их уменьшения необходим единый центр печати текстовой и графической документации. Это позволяет вести учет работ и минимизировать затраты на расходные материалы (бумагу и картриджи) и обслуживание периферийной техники (принтеров, плоттеров).
- Закрытость системы извне. Действительно, современные системные блоки не содержат флоппи-дисководов. Обмен документами выполняется по электронной почте или через общие каталоги на локальных рабочих станциях проектировщиков или серверах. Целью такого решения является, прежде всего, борьба с вирусами, устранение утечки корпоративной информации и предотвращение распространения нелегального программного обеспечения (последнее требует также лишение пользователей соответствующих прав локальных администраторов). Внешняя корреспонденция (электронная почта) поступает и отправляется через администратора электронной почты с обязательной отметкой в журнале учета, проверкой на вирусы и последующим архивированием на оптический диск.
- Единство инструментальных средств. Действительно, последовательно необходимо проводить политику использования единых лицензионных инструментальных средств, разрешенных к применению в проектной организации (системы Microsoft Windows XP, Vista, 7, графики Paint.NET (бесплатного аналога Adobe Photoshop), таблицы/текст Open Office (российской разработки – бесплатного аналога Microsoft Office, AutoCAD, КОМПАС-3D и т.д.). Возможно, выбор единой программной среды может затянуться, что замедлит темпы внедрения информационных технологий, появятся недостающие шрифты AutoCAD на некоторых рабочих станциях и т.д., и, как следствие, приведет к общему увеличению времени проектирования.
- Постоянное повышение квалификации. Действительно, обязательно необходимо выделить специальные ресурсы (людские, технические, временные и экономические) на повышение квалификации по освоению используемого и нового программного обеспечения и отработке технологии командной работы коллектива специалистов над одним проектом.
Процесс проектирования представляет собой сложную информационную систему с большим числом участников, множеством параллельных, пересекающихся, встречных и цикличных связей между ними и большими объемами передаваемой информации. Обеспечение информационного взаимодействия различных подразделений и специалистов в рамках командной работы над проектом – это самая актуальная задача в настоящий момент.

В своем развитии автоматизированное проектирование, как информационная система, проходит несколько этапов, характеризующих способ организации данных на электронных носителях:
1. Проектные документы готовятся на отдельных компьютерах не связанных между собой в локальную сеть. С внедрением автоматизированного проектирования появляются новые, электронные, формы документов. Они накапливаются в больших количествах на компьютерах пользователей без единой системы хранения и учета. Не систематизировано и внесение изменений. Размножение документации производится с бумажных носителей, что приводит к их преждевременному износу, разрастанию архива, требует для него дополнительных площадей, и, как следствие, является тормозом в развитии технологии проектирования. При этом ведется произвольный обмен каталогами архивами и файлами. Передача документов между соисполнителями осуществляется на внешних накопителях небольшого объема (дискетах, флэш-дисках, компакт-дисках и т.п.), движение документации по определению медленное, порождающее большое количество различных копий одного и того же документа. Форматы обмена ASCII и dxf.
2. Подготовка проектных данных на рабочих станциях, включенных в локальную сеть. При этом резко возрастает скорость обмена, возникают первые предпосылки тесного взаимодействия между подразделениями. Появляются общие каталоги обмена на сервере и локальных машинах, требуется стандартизация (ограничение) на форматы документов, возникает необходимость разработки единой маркировки файлов. На файловой структуре невозможно построить документооборот, так как имеются ограничения на имена файлов, невозможно отслеживать маршрут и историю документов и пр. Хотя в серверной операционной системе Microsoft Windows Server 2003 и 2008 имеется возможность разграничения прав доступа групп пользователей к документам, это не решает проблему большого количества копий файлов. Появляются первые признаки совместной (командной) работы различных подразделений над общим проектом. От заказчика и смежников начинают поступать исходные и промежуточные данные в оцифрованном виде. Возникает потребность централизованного архива проектной документации, а также задача централизованного восстановления данных. Форматы обмена становятся более интеллектуальными, передаются шрифты, стили, блоки (doc, xls, dwg, dgn, pdf и др.).
3. Использование сервера для хранения электронных проектных данных на основе СУБД. Каждый проектировщик имеет персональный компьютер с одним или двумя мониторами, некоторые – мобильные рабочие станции (ноутбуки, нетбуки, смартфоны и т.п.). Документы хранятся не как отдельные файлы, а как записи в базе данных. К документам прилинкованы атрибуты (автор, дата создания, изменения и просмотра и др.), возможны четкое отслеживание версий и маршрута движения документа, выборки, сортировки, архивирование, откат и т.д. Обеспечивается безопасный коллективный доступ для различных групп пользователей. Поиск и извлечение документов из базы данных организовано через Intranet. Основная сложность заключается в том, что клиентские приложения не могут работать напрямую с документами, хранящимися в БД. Появились обменные форматы и конверторы, информационное обеспечение становится ключевым.
4. Применение промышленных систем управления проектной документацией. Главной целью предыдущего третьего этапа является создание условий для построения системы электронного документооборота, в том числе научиться описывать связи, составить регламент, определить права, загрузить документы в базы данных и, главное, осознать всем исполнителям необходимость и пользу работы в этих условиях. Единых форматов хранения и работы в ближайшем будущем ввиду гибкости САПР не предвидится, хотя потери от преобразований будут минимальны.

Сформулируем основные требования к единому информационному пространству проектной организации:
- Реальное время. Информационная система проектной компании должна функционировать в режиме реального времени, то есть выполнение проектной документации происходит одновременно с принятием проектных решений.
- Коллективная работа над проектом. В первую очередь это упорядоченный, обмен информацией на электронных носителях. Простота копирования документов в условиях развитой локальной сети – это огромное достижение, но одновременно и настоящее бедствие, так как графические документы, пояснительные записки, сметы и т.д. быстро размножаются, дублируются, теряют авторство и начинают жить своей жизнью. Как результат, резко теряется актуальность.
- Разграничение доступа. Любой документ в проектной организации имеет автора, который определяет местоположение документа (подчиненность), его достоверность (степень готовности) и доступность другим. С другой стороны каждый специалист имеет доступ к информации в соответствии со своим статусом.
- Два уровня информационных потоков внутренний (внутри проектной организации между специалистами и подразделениями) и внешний (между компанией и заказчиком, субподрядчиками и т.д.). Каждый из уровней имеет свои правила движения информации. Внутри организации перемещения документов носит менее формальный характер, чем внешние (выдача технического задания, внесение исправлений, оповещения и согласования по телефону и электронной почте). Существуют специальные процедуры на отмену, изменение и дополнение документов, переданных вне проектной организации.
- Единство форматов документов. Машинный способ обмена документацией, в отличие от традиционного бумажного способа, накладывает существенное ограничение на применяемые форматы данных. Внутри проектной организации необходимо принять специальные меры по соблюдению стандарта обмена, а внешний обмен основывается на предварительных соглашениях, либо применением специальных конверторов (в некоторых случаях, к сожалению, с потерей информации, необходимостью переобучения пользователей и затрат времени, сопоставимых со временем разработки документа). Ключевые документы для выполнения работ в базах данных.

Рассмотрим место ИТ-службы в пространстве проектной организации.

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

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

Итак, мы выяснили, какие основные внешние объекты должны быть учтены в ЕИП ИТ-службы.

Рассмотрим функции ИТ-службы (состав ИТ-услуг).

ИТ-служба занимается оказанием услуг проектной организации, в основном, трех видов:
- строительство инфраструктуры. Отнесем их к работам по построению информационно-вычислительных сетей (ИВС) – установка компьютеров, формирование сетевых соединений в рамках локальной сети, оснащение компьютеров базовым программным обеспечением, формирование сервисов общего назначения (Интернет, электронной почты, системы защиты информации);
- разработка и внедрение. Эти термины мы в данном случае отнесем к интегрированным и специализированным программным приложениям, обеспечивающим ИТ-среду для выполнения основной работы пользователей;
- эксплуатация всего построенного и внедренного.

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

Рассмотрим объекты ЕИП ИТ-услуг и функциональные модули системы управления ими.
Ветка разработки и внедрения
Бизнес-моделирование
Центральным звеном системы управления ИТ-услугами являются пользователи. Пользователь характеризуется своим рабочим местом (РМ) и своим «портретом». РМ необходимо, в соответствии с требованиями заказчика, оснастить и далее поддерживать оснащение в рабочем состоянии. Персону необходимо обучить и потребовать выполнять предписанные требованиями к РМ функции в автоматизированной информационной системе (АИС) организации, выполняющей проектные работы.

Откуда берутся РМ? Вероятно, информационным объектом, поставляющим их, является структура управления организацией, выполняющей проектные работы, следовательно, в нашем ЕИП надо предусмотреть для нее место. Привязка персоны к РМ – суть штатное расписание. При посменной работе к одному РМ может быть приписано несколько работников.

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

Затем – процессы, обеспечивающие исполнение функций. На каждую функцию их, в общем случае, несколько. Процессы связывают РМ между собой в цепочку или (если в процессе присутствует ветвление) в сеть. Разумеется, РМ может участвовать в нескольких процессах.

Мы будем называть эти процессы информационными процессами (ИП) в отличие от более традиционного «бизнес-процессы» (БП). Цель ввода этого понятия – строгость определения, необходимая для наших задач. Под БП теперь кто угодно понимает что угодно. В наиболее широком смысле в это понятие включают и производственно-технологические процессы, которые нас в данном случае не интересуют, и управленческие процессы, не затрагивающие непосредственно АИС. В свете этого мы определяем ИП для нашего случая как некоторую проекцию БП на АИС. Как уже отмечалось, ИП – это граф, вершины которого – РМ, а дуги – отображение последовательности исполнения операций процесса. Каждой вершине можно сопоставить несколько вещей: вход (исходные данные), выход (информационные результаты), инструментарий (программная обработка и технологическая инструкция). Как видим, объектов прибавилось. Посмотрим внимательней на некоторые из них, и продвинемся в создании новых, перейдя в следующий модуль.

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

Далее возникают права доступа. С каждого РМ, представленного в каждом ИП, необходимо иметь право читать объекты входа и писать в объекты выхода. Это несколько упрощенный (на уровне общей схемы ИП) подход; возможны требования дополнительно обусловить те или иные права в контексте конкретного ИП; возможно довести эти требования и до полей данных. Отнесем эти тонкости к специальным требованиям заказчика, реализуемым уже не через уровень прав доступа к объектам метаданных, а через собственно программные коды обработок. Требования эти, естественно, должны быть как-то зафиксированы в системе.

Права доступа могут быть реализованы или индивидуально для каждого РМ или через шаблоны ролей в целях экономии затрат на проектирование. Отсюда появляется объект «роли».

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

Отметим, что при внедрении тиражных приложений мы определяем стандартную и рабочую конфигурации, отличающиеся наличием новых объектов метаданных (включая и программные обработки) и, возможно, модификацией стандартных.

Ветка строительства инфраструктуры
Здесь все, с точки зрения объектов ЕИП, достаточно просто. У нас имеются РМ и требования к их участию в ИП. Соответственно, возникают требования к программно-аппаратному оснащению каждого РМ. Если они укладываются в принятый в выполняющей проектные работы организации стандарт оснащения клиентского места, к этому РМ привязывается стандартная его конфигурация, если нет, возникает требование на специализированную. Равно как и с сетевыми соединениями, серверными конфигурациями и т.п., требования к которым возникают из совокупности требований ко всем РМ, их географического расположения и т.п. Соответственно возникают такие объекты, как сети, серверы, клиентские рабочие станции (терминалы), сетевое оборудование, сетевые соединения, описание которых необходимо как в целях генерации работ для их построения, так и для последующей эксплуатации.

Ветка эксплуатации
Эксплуатируются все созданные в процессах строительства инфраструктуры, разработки и внедрения объекты; новые виды объектов эксплуатация почти не порождает. Исходной точкой действий по эксплуатационным услугам (или услугам поддержки и сопровождения) является эксплуатационное требование, исходящее, как правило, от пользователя. Существенным с точки зрения системы объектов ЕИП можно здесь считать то обстоятельство, что процесс сопровождения порождает такие явления, как версии исходных объектов, каковые сами по себе обретают статус объектов и обрастают своими процедурами управления.

Управление требованиями
Целесообразно выделить два вида требований: требования заказчика и требования пользователя. Сразу оговоримся, что структура их отражения в ЕИП практически одинакова для обоих видов; различия проявляются на качественном уровне и на уровне процедур управления.

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

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

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

Рассмотрим управление работами.

Принятое требование порождает одну или несколько работ (новый для нас вид объекта). Соответственно, необходимость управлять исполнением работ (заданий) порождает целый блок дальнейших объектов.

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

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

Соответственно, возникает такой вид объекта, как ресурсы. Для наших целей интерес представляют ресурсы, в основном, двух видов – трудовые и финансовые; такие вещи, как, например, оборудование или материалы редко ограничивают возможности выполнения работ в зоне ИТ-услуг.

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

Рассмотрим общую структуру.

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

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

Общий вид структуры полученного единого информационного пространства
Общий вид структуры полученного единого информационного пространства


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

Теперь проектная документация, разрабатываемая проектной организацией ООО «Челябэнергопроект» и партнерами помещается в единое хранилище – электронный архив по схеме хранения данных в виде файлов формата графических, текстовых редакторов и САПР.

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

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

Разработанная система хранения данных основана на базовой (бесплатной) версии системы электронного документооборота NauDoc с открытым исходным кодом, что позволяет совершенствовать систему: расширить функционал и улучшить удобство использования интерфейса с учетом пожеланий пользователей силами ИТ-специалистов компании.


Источники:
1. Васильев, К., Стольберг, Е. Концепция ЕИП в управлении ИТ-службой. – 2008 [http://www.cfin.ru/itm/irp.shtml]
2. Пальянов, П.А. Интранет способ организация единого информационного пространства проектного института. Из материалов пятой конференции ГИС-Ассоциации Геоинформатика и образование» (Москва, 5-8 июня 2001 г.). http://www.gisa.ru/867.html
3. Бубнов, М. Создан электронный архив // Выксунский Металлург. – 2009. – №34 – С.2 [http://construction.ascon.ru/source/articles/electronny_arhiv.pdf]

Автор: Челябэнергопроект
Дата: 23.03.2010

Комментарии специалистов Челябэнергопроект:
Нет
Статьи

смета проектных работ
©Челябэнергопроект – проектные работыinfo@chepr.ru, 2007-2013
DRA.RU - проектирование сайта под ключ; системный администратор ООО «Челябэнергопроект»
Главная|О компании|Стратегия|
Компетенция / услуги|Контакты
Сертификат качества