CC BY
152
3. Стариков А. Ядро OLAP системы // Лаборатория Base-Group. 2003. URL: http://www.basegroup.ru/ (дата обращения: 23.08.2013).
4. Ковтун М.В. Реализация ELT-процессов корпоративного хранилища данных // Корпоративные хранилища данных. Интеграция систем. Проектная документация. 2011. URL: www.prj-exp.ru (дата обращения: 23.08.2013).
5. Ястребкова Е. Элиминирование внутригрупповых оборотов при консолидации // МСФО: практика применения. 2006. № 6. С. 54-61.
6. Ястребкова Е. Консолидация отчетности при использовании в производстве активов, закупленных внутри группы // МСФО: практика применения. 2007. № 2. С. 20-30.
References
1. Shitov D., Baev N. Ekonomika biznesa [Business economics]. 2008, no. 06 (42), pp. 4-5.
2. Barsegyan A., Kupriyanov M., Stepanenko V., Holod I. Tekhnologii analiza dannykh. Data Mining, Text Mining, Visual Mining, OLAP [Data analysis technologies. Data Mining, Text Mining, Visual Mining, OLAP]. St. Petersburg, BHV-Petersburg Publ., 2007, pp. 19-58 (in Russ.).
3. Starikov A. Yadro OLAP sistemy [The core of OLAP system]. BaseGroup, 2003, available at: http://www.basegroup.ru/ (accessed 23 August 2013).
4. Kovtun M.V. Korporativnye khranilishcha dannykh. Integratsiya sistem. Proektnaya dokumentatsiya [Data Warehouse. Systems integration. Project documents]. 2011, available at: http:// www.prj-exp.ru/dwh/implementation_of_etl_process.php (accessed 23 August 2013).
5. Yastrebkova E. MSFO: praktika primeneniya [IFRS: practice]. 2006, no. 6, pp. 54-61.
6. Yastrebkova E. MSFO: praktika primeneniya [IFRS: practice]. 2007, no. 2, pp. 20-30.
УДК 355.01: 004.056
АВТОМАТИЗИРОВАННОЕ ФОРМИРОВАНИЕ ПЕРСОНАЛЬНЫХ ДОЛЖНОСТНЫХ ИНСТРУКЦИЙ СОТРУДНИКОВ ПРОЕКТНЫХ ОРГАНИЗАЦИЙ
П.И. Соснин, д.т.н., профессор, зав. кафедрой; К.В. Святов, к.т.н., доцент, директор центра новых информационных технологий
(Ульяновский государственный технический университет (УлГТУ), ул. Северный Венец, 32, г. Ульяновск, 432027, Россия, [email protected], [email protected]); А.А. Перцев, соискатель (УлГТУ), начальник отдела (НПО «Марс», ул. Солнечная, 20, г. Ульяновск, 432022, Россия, [email protected])
Рассмотрены процессы коллективной разработки сложных автоматизированных систем, компетенции проектной организации и ее членов. Особое место занимает конструктивное управление организационными ресурсами и опытом проектной организации, поскольку результативность работы любой проектной организации в существенной мере зависит от профессионального опыта и компетенции ее специалистов. Основной формой группирования компетенций являются роли, с каждой из которых связывают не только группу компетенций, но и инструментально-технологическое обеспечение. Для закрепления ответственности конкретных членов проектной организации необходимо персонифицировать должностные инструкции и закреплять их в договорных обязательствах. Для формализации системы персонифицированных должностных инструкций членов проектной организации используется онтологический подход. Основная часть статьи посвящена инструментальным средствам автоматизированного формирования персонифицированных должностных инструкций сотрудников проектной организации, разрабатывающей семейства автоматизированных систем. Реализация ориентирована на процессы проектирования, для информационного обслуживания которых используется база опыта.
Ключевые слова: автоматизированное проектирование, база опыта, должностная инструкция, профессиональная зрелость.
AUTOMATED ORGANIZATION OF PERSONAL JOB DESCRIPTIONS FOR DESING ORGANIZATIONS EMPLOYEES Sosnin P.I., Dr. Tech. Sc., professor, head of chair;
Svyatov K.V., Ph.D. Tech. Sc., associate professor, director of Center for New Information Technology (Ulyanovsk State Technical University (UlSTU), Severny Venets St., 32, Ulyanovsk, 432027, Russian Federation,
[email protected], [email protected]);
Pertsev A.A., candidate (UlSTU), head of department (Research-and-Production Association «Mars», Solnechnaya St., 20, Ulyanovsk, 432022, Russian Federation, [email protected]) Abstract. The paper considers the processes for the collective development of complex automated systems (software intensive systems), and the competencies of a design organization and its members. The constructive management of organizational resources and design organization experience is very important. Its efficiency depends highly on professional experience and employee competency. A common form for the competency grouping is roles. Every role is linked not only to a group of competencies, but to an engineering tool set. Assignment of employees' responsibilities needs job descriptions to
be personalized and consolidated in the commitments. To make a system of personalized job descriptions, an ontological approach is used. This paper presents tools for automated creating of personalized job descriptions for employees of a design organization developing computer-aided systems (CAS). The implementation is focused on design processes that use experience base for information support.
Keywords: CAD, experience base, job description, professional maturity, competence.
В процессах коллективной разработки сложных автоматизированных систем особое место занимает конструктивное управление организационными ресурсами, нашедшее свое нормативное представление в стандарте People Capability Maturity Model (CMM) (http://www.sei.cmu.edu/cmmi). Этот стандарт регламентирует работу сотрудников проектной организации, ориентируясь на модель профессиональной зрелости процессов CMM и адаптируя ее к процессам управления рабочей силой (work force) и ее совершенствования.
Конкретная организация на основе данного стандарта должна специфицировать свою систему компетенций, необходимых для успешной деятельности, создавать условия для материализации компетенций (подбор кадров, профессиональное обучение и т.д.), а также распределять ответственность между сотрудниками организации за использование компетенций в процессах разработки автоматизированных систем.
В настоящее время серьезное внимание уделяется спецификациям компетенций при разработке систем, к которым относятся и автоматизированные системы, интенсивно использующие ПО (Software Intensive Systems, SIS). Одним из результатов работ по спецификации компетенций является так называемое колесо компетенций (Competence Wheel) [1], объединяющее (с позиции компетенций) 11 процессных областей по уровням зрелости, в которые собрано около 400 ключевых областей деятельности. Это колесо с аббревиатурами направлений обобщенно представлено на рисунке 1. В число направлений, например, входят бизнес-процессы (CMM-BP, Business Processes) и бизнес-модели (CMM-BM, Business Models), в рамках которых перечислены компетентности с группированием. Данные компетентности при-
CMM-VM
CMM-BM CMM-PM
CMM-SO
CMM-MDM CMM-ITSW
Рис. 1. Колесо компетенций
нято обязательно называть, в частности, в должностных инструкциях сотрудников организации.
Распространенной формой группирования компетенций являются роли. С каждой ролью связывают не только группу компетенций, но и инструментально-технологическое обеспечение, обслуживающее ее исполнение сотрудником (проектировщиком).
Понятие «роль» является одним из центральных в технологии Rational Unified Process (RUP), обслуживающей исполнение совокупности ролей, в которую входят роли «руководитель проекта», «системный аналитик», «архитектор» и др. [2].
Роль в рамках какой-либо технологии - это нормативная спецификация профессиональных действий, исполнение которых в инструментально-технологической среде нацелено на решение задач, приводящих к созданию определенной совокупности артефактов. За исполнением роли всегда стоит экспериментирование в процессах решения определенного круга задач, причем решения в соответствии с определенными нормативными правилами и сценариями (методиками). Полезной формой описания роли является ее представление в виде должностной инструкции, доведенной в деталях до возможности результативного и эффективного применения должностной инструкции компетентными исполнителями роли.
Реальность проектирования такова, что конкретную роль по разным причинам могут исполнять несколько проектировщиков, а конкретный проектировщик - исполнять несколько ролей. В таких условиях для юридического закрепления ответственности конкретного сотрудника проектной организации должностные инструкции персонифицируют и закрепляют в договорных обязательствах за исполнителями работ, названных в персонифицированных документах. В статье представлено автоматизированное формирование персонифицированных должностных инструкций в инструментально-моделирующей среде Working In Questions and Answers (WIQA) [3], на основе которой создается база опыта проектной организации [4].
Компетентность проектной организации
Результативность любой проектной организации во многом определяется тем, какой профессиональный опыт E*(t) ей необходим и в каком объеме E(t) этот опыт на текущий момент времени t освоен членами {Dv} коллектива K({Dv}, t). Динамика выделенных сущностей обусловлена рядом причин, в первую очередь совершенствова-
CMM-BP
CMM-EA
Business Process - CMM-BP
Initial and chaotic:
n No/Minimal established | | processes
d Work performed in an ad I I hoc fashion
□ No standardization Q across enterprise
D Process ownership
□ partially defined
□ Documentation is minimal
□ and not shared
□ Process teams are ad
□ hoc
I I Process projects and
□ teams are ad hoc
Q No dedicated Business Q process development team
Some processes are repBatable:
n Minimal documented, I I implemented processes with owners identified
□ Some process standardi-
□ zation across enterprise
□ Processes documented. Q communicated as they
are approved or periodically (ad hoc fashion)
□ No dedicated Business |—| process development
team
| | Process teams and |—| projects work with centralized focus (virtual cr not virtual)
□ Some business process Q ownership
Defined and documented standard processes established and subject to some degree of improvement over time:
□ Standardized processes,
□ at the department level or above, with periodic updates
[J Processes competencies
□ documented and communicated formally
□ Process lessons learned
□ Is initiated
I I Process ownership held
□ with the business
□ Green processes are
□ Identified and green sustainability processes are incorporated
□ Dedicated Business
□ process team
Managed processes:
| | Migrating to standardized
□ enterprise processes with periodic updates
I I Process ownership held Q with the business
Q Processes documented,
□ trained/ shared / communicated frequently
Q Processes measured and
□ managed periodically
□ Process lessons learned |—|| incorporated -rrfljor
changes
| | Process competency |—| developement team are dedicated to ensure innovation, transformation, performance and is received
□ Process Governance is
□ fully integrated with:
• Corproate Governance
• IT Governance
• Service Governance
• Enterprise Arc. Gov.
Optimized - continually improving process performance through both incremental and innovative technological changes/improvements:
I I Processes Governance is qj used for continuous improve rrrent
Q Standardized enterprise pi processes with periodic updates
□ Process lessons learned I—i incorporated for all
'—' changes
□ Processes fully aligned I I with performance
management & governance
□ Enterprise-wide Business
□ Value Management incorporated in business process optimization and innovation
□ Business Processes fully
□ aligned with business architecture and Value Governance
□ Process team has
□ ownership
Рис. 2. Перечень компетенций в контексте совершенствования процессов
нием производственных процессов, разработкой новых проектов и текучестью кадров, что указывает на необходимость управления уменьшением различий между E*(t) и E(t) и распределением E(t) между членами коллектива K({Dv}, t). Более того, в управлении отмеченными процессами следует учитывать не только единицы опыта E*(t), но и то, в каком количестве каждая из них необходима для решения задач организации.
В реализации отмеченного управления важное место занимает структуризация опыта E(t) с позиций его представления как компетентности проектной организации, что позволяет ввести в структуризацию элементы знаний, умений и навыков, а с их помощью специфицировать компетенции, необходимые для решения каждой из нормативных задач {ZNip} технологий {Tp}, используемых в проектной организации. Именно такой способ используется в технологии RUP для спецификации ролей, которые она поддерживает методически и инструментально.
В колесо компетенций его создателями введены названия компетенций, абстрагированные от технологий и распределенные по 11 процессным областям, обеспечивающим разработку SIS. Одна из таких областей (CMM-BP) обобщенно изображена на рисунке 2 с демонстрационными целями,
без объяснения и перевода, только для того, чтобы отметить, что подобные формы существуют и удобны для моделирования направлений деятельности проектной организации с точностью до уровня должностных инструкций работников. С другой стороны, формализация задач в цепочке стратегия развития организации - положения о подразделениях - должностные инструкции работников позволяет распределить ответственность каждого отдельно взятого работника, а самое главное, ответственность закрепляется юридически и финансово. Графически источники информации для формализации задач можно представить в виде схемы (рис. 3).
Оргструктура
Компетенции
Документы
Формализованное описание должности
Планы работ
Инструкции
Инструменты
Рис. 3. Формализация описания должности с онтологической точки зрения
Ориентация на онтологию рисунка 3 приводит к следующему представлению системы должностных инструкций: JD=S({JDp, JDc, JDd, JDwp, JDins, JDi}, 0, где JDp - представление должности в оргструктуре; JDC - компетенции, необходимые для данной должности; JDd - весь набор необходимых документов для обеспечения деятельности; JDwp -множество плановых заданий; JD,m - необходимый набор инструкций; JD, - используемое множество инструментов; t - время.
Позиция JDp определяется организационной структурой предприятия и связана со следующими атрибутами: уровень иерархии, функциональное подчинение, административное подчинение, функциональное управление, административное управление, задачи.
Компетенции JDC, с одной стороны, определяются соответствием процессным областям колеса компетенций, с другой - личностными качествами человека, например, стремление к лидерству, способность анализировать и решать проблемы, инициативность, инновативность, нацеленность на результат, настойчивость, работа в команде, планирование деятельности.
Каждый документ JDd однозначно определяется набором атрибутов. Приведем минимально необходимый набор: уровень иерархии выпуска документа; статус документа (нормативный, распорядительный, информационный); область использования; актуальность; назначение документа; основные термины и определения; область применения документа (кому предназначен); контролирующие органы применения документа; классификация информации, используемой при применении документа; требования к информации; источники получения информации; технология и технические средства получения (сбора), обработки, передачи, накопления и использования информации.
Плановые задания JDwp характеризуются атрибутами: источник возникновения, задача (конечный результат), срок выполнения, приемщик, ресурсы для выполнения.
Прежде всего инструкция JDim - это документ, содержащий правила, указания или руководства, устанавливающие порядок и способ выполнения или осуществления чего-либо.
Инструменты JD, определяются следующими атрибутами:
объект воздействия, способ применения, решаемая задача, полезный эффект, вспомогательный материал, необходимая инструкция.
Предложенная формализация должностной инструкции представима как задача класса задач Z*. Одним из инструментов моделирования задач типа Z* является инструментальная среда WIQA.
Формирование должностных инструкций в среде процессора WIQA
Для создания персонифицированных должностных инструкций JD был разработан комплекс специализированных средств и встроен в систему WIQA.NET. К настоящему времени в WIQA.NET реализована подсистема документирования, позволяющая формировать любые документы по их шаблонам в Microsoft Word (MS Word) и шаблонам в виде дерева вопросно-ответных единиц, а на ее основе реализована подсистема формирования должностных инструкций.
Сама задача формирования должностных инструкций подразумевает, что пользователь, ответственный за выполнение данной работы, простыми действиями в системе WIQA может создать отформатированный документ MS Word, оформленный в соответствии с нормативами, установленными в проектной организации. Для реализации данной задачи были использованы возможности подсистемы документирования в сочетании с надстройкой над плагином оргструктур, в котором реализована возможность выбора позиций JD для должностной инструкции конкретного сотрудника из справочника. Справочник представлен в виде проекта в вопросно-ответном протоколе в проекте «Архив активов». Общий вид подсистемы формирования должностных инструкций дан на рисунке 4.
Рис. 4. Схема формирования должностной инструкции
Из рисунка видно, что центральным хранилищем для должностных инструкций конкретного сотрудника является вопросно-ответный протокол, в котором для каждого сотрудника назначается отдельная задача. Сами документы (MS Word) генерируются на основе данных вопросно-ответного протокола и шаблона оформления документа (MS Word) в системе документирования.
Все множество доступных должностных инструкций JD* хранится в вопросно-ответном протоколе в проекте «Архив активов» в задаче «компетенции». При этом при редактировании данного архива следует учитывать следующие правила назначения атрибутов (чтобы список инструкций для конкретной должности отображался корректно).
1. Каждая QA-единица, являющаяся укрупненной компетенцией JDc, должна иметь атрибут «групповая компетенция».
2. Каждая QA-единица, являющаяся должностью JD, должна иметь атрибут «должность».
3. Каждая единица, которая в качестве дочерних содержит конкретные компетенции JDc, должна иметь атрибут «компетенция».
Для адресации точек вставки данных в шаблон были разработаны контекстно-зависимые атрибуты, которые используются только при формировании шаблона отчета (в среде Microsoft Word) [5].
В общем виде работа оператора по формированию должностных инструкций состоит из этапов, представленных на рисунке 5.
Формирование и изменение документа должностной инструкции
Практическая работа с должностными инструкциями осуществляется в плагине «Организационная структура». В основном окне «Данные сотрудника» необходимо выбрать пункт меню «Сотрудники», в появившемся диалоговом окне необходимо выбрать работника, для которого формируется должностная инструкция. Назначив должность работника на вкладке «Работа», можно просматривать и редактировать должностные обязанности работника на вкладке «Должностные инструкции». На вкладке «Роль» можно уточнить роль, выполняемую данным работником.
Должностные обязанности выбираются выделением в соответствующем поле маркером. Первоначально обязанности работника определяются ролью, затем могут корректироваться в процессе работы.
Для сохранения внесенных изменений необходимо выбрать проект и задачу в QA-протоколе, для которой предполагается сохранить инструкцию. Также необходимо выбрать шаблон с общими данными для документа и шаблон отчета в MS Word. При нажатии на кнопку «сохранить» происходит следующее.
Рис. 5. Порядок работы с должностными инструкциями для пользователя
1. Вопросно-ответный шаблон копируется в выбранную задачу вопросно-ответного протокола вместе со всеми своими подчиненными шаблонами и атрибутами.
2. Измененные элементы инструкций скопи-руются в качестве дочерних к рЛ-единице, созданной на основе шаблона. Причем скопируется структура компетенций, отфильтрованная также (кроме пользовательского выбора элементов) по должности.
3. В плагине «Проектная документация» создастся папка «Должностные инструкции», если ее не было (если была, она откроется), в которой сге-нерируется должностная инструкция на основе выбранного шаблона представления и выбранной задачи вопросно-ответного протокола.
После формирования инструкцию можно посмотреть в плагине «Проектная документация» в папке «Должностные инструкции».
Для изменения или дополнения общих данных документа (номер, информация о подписывающих и согласующих и т.п.) в плагине «Вопросно-ответный протокол» необходимо открыть вновь добавленную задачу и измененить сведения. После внесения изменений документ будет содер-
жать обновленные данные, так как при каждой генерации используется информация из конкретного экземпляра. Дополнительно предусмотрено формирование шаблона на основе конкретного экземпляра QA-протокола.
Структура вопросно-ответного протокола с должностными инструкциями полностью соответствует структуре самого документа.
Подводя итоги, отметим, что представленные в статье средства автоматизированного формирования должностных инструкций нацелены на персонификацию профессиональной ответственности сотрудников проектной организации. В разработке средств учтены современные стандарты профессиональной зрелости процессов и их организационного сопровождения. Предложенные и материализованные решения ориентированы на их включение в базу опыта проектной организации.
Литература
1. Von Rosing M., Moshiri S., Graslund K. & Rosenberg A. Competency Maturity Model Wheel. URL: http://www.value-team.biz/downloads/ model_cmm_wheel.pdf (дата обращения: 13.09.2013).
2. Borges P., Machado R.J. & Ribeiro P. Mapping RUP Roles to Small Software Development Teams. Proc. Intern. Conf. on Software and System Process (ICSSP). Portugal, 2012, pp. 190-199.
3. Соснин П.И. Вопросно-ответное программирование человеко-компьютерной деятельности. Ульяновск: УлГТУ,
2010. 240 с.
4. Маклаев В.А. Подход к представлению и использованию профессиональных активов проектной организации // Автоматизация процессов управления. 2011. № 1 (23). С. 5-12.
5. Sosnin P. Pseudo-code programming of designer activity in development of software intensive systems. Proc. 25th Intern. Conf. on Industrial Engineering and other Applications of Applied Intelligent Systems (IEA/AIE 2012). Dalian, Chine, 2012, pp. 457-466.
References
1. Von Rosing M., Moshiri S., Graslund K., Rosenberg A. Competency Maturity Model Wheel. Available at: http://www.va-lueteam.biz/downloads/ model_cmm_wheel.pdf (accessed 13 September 2013).
2. Borges P., Machado R.J., Ribeiro P. Mapping RUP roles to small software development teams. Proc. int. conf. on software and system process (ICSSP). Portugal, 2012, pp. 190-199.
3. Sosnin P.I. Voprosno-otvetnoe programmirovanie chelove-ko-kompyuternoy deyatelnosti. Ulyanovsk, Ulyanovsk St. Tech. Univ. Publ., 2010, 240 p.
4. Maklaev V.A. Podkhod k predstavleniyu i ispolzovaniyu professionalnykh aktivov proektnoy organizatsii. Avtomatizatsiya protsessov upravleniya [Automation of management processes].
2011, no. 1 (23), p. 5-12.
5. Sosnin P. Pseudo-code programming of designer activity in development of software intensive systems. Proc. 25th intern. conf. on Industrial Engineering and other Applications of Applied Intelligent Systems (IEA/AIE 2012). Dalian, Chine, 2012, pp. 457-466.
УДК 004.023
УПРАВЛЕНИЕ ПРОЕКТОМ ПО СОЗДАНИЮ ПРОГРАММНОЙ СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА
(Работа выполнена при поддержке РФФИ, грант № 12-01-01005-а)
В.Н. Кузнецов, д.т.н., профессор, зав. кафедрой; Н.Ю. Мутовкина, к.т.н.., доцент; С.А. Чудов, аспирант (Тверской государственный технический университет, наб. Аф. Никитина, 22, г. Тверь, 170026, Россия, [email protected])
Рассмотрен метод системного анализа принятия решений по созданию системы электронного документооборота. Данный метод, основанный на принципе согласованного управления и законах согласованного планирования, включает эвристические процедуры и нечеткую логику. Разработаны неформальные процедуры управления проектом системы электронного документооборота. Осуществлены формализация и постановка задачи принятия решений в расплывчатых условиях с расплывчатой коалицией. Расплывчатость (нечеткость) является одним из основных источников неточности в процессах согласованной оптимизации. При принятии решений люди в основном применяют расплывчатые понятия и выполняют расплывчатые инструкции. Кроме того, во многих случаях они имеют разные мнения относительно конкретной проблемы и способов ее устранения. Следовательно, зачастую решение принимается в условиях конфликта. Для смягчения конфликтных ситуаций при разработке программных средств, в частности системы электронного документооборота, предлагается применение хорошо известных методов согласованного управления и планирования, входящих в состав метода системного анализа. Именно различием в целях, мнениях и интересах обусловлена необходимость формирования новых принципов построения информационно-управляющих систем поддержки принятия решений.
Ключевые слова: информационно-управляющая система, принятие решений, методы системного анализа, нечеткая логика, нечеткий вывод.
PROJECT MANAGEMENT WHEN CREATING SOFTWARE SYSTEM FOR ELECTRONIC WORKFLOW
Kuznetsov V.N., Dr. Tech. Sc., professor, head of chair;
Mutovkina N.Yu., Ph.D. Tech. Sc., associate professor; Chudov S.A., postgraduate student (Tver State Technical University, Quay Nikitin, Tver, 22, 170026, Russian Federation, [email protected])
