Розробка посадових інструкцій на основі функціональної моделі AllFusion Process Modeler 4.1.4., Різне, Програмування, статті

                                                                                                                                                                                                         

© Дубейковскій В.І.

Системний аналітик Відділу впровадження та консалтингу компанії «ІНТЕРФЕЙС»


Все більш широкий попит у вітчизняній виробничій практиці знаходить завдання формалізації посадових обов’язків співробітників. Цей попит визначається намірами оптимізувати організацію роботи підприємства. Розширюється попит викликає генерацію пропозицій послуг відповідного профілю. До теперішнього часу на ринку надання послуг створення посадових інструкцій виникло кілька вузько спеціалізованих підприємств. Як правило, методично їх робота прокламується коректно побудованої на використанні функціонального моделювання роботи підприємства. Часто – з використання IDEF0. Однак як інструментарію моделювання використовуються, як правило, спрощені самодіяльні технології.

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


Важко уявити переваги використання локальних засобів функціонального моделювання, для цих цілей, – перед використанням пакета прикладних програм світового загальновизнаного класу AllFusion Process Modeler. Як правило, причини використання самодіяльних вітчизняних розробок носять той або інший приватний, вузький, погано обгрунтований характер.


Цілком усталена традиція ділить посадову інструкцію на два розділи:



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


Посадові обов’язки характеризують виробничі відносини і грунтуються на предметно-технологічних особливостях роботи підприємства. Ці особливості ефективно можуть бути описані в форматі ФМ роботи підприємства.


Таблиця 1. Структура посадових інструкцій[1]





















































№ з / п


Структура ДІ


Зміст ДІ


1


Прізвище, ім’я, по батькові


2


Посада


3


Загальні положення


4


Кваліфікаційні вимоги


5


Внутрішні і зовнішні регламентуючі документи


6


Посадові обов’язки


7


Права


8


Відповідальність


9


Умови роботи


10


Умови оплати праці


11


Прикінцеві положення


У штатному поданні функціональної моделі AllFusion Process Modeler розроблена в її межах організаційна діаграма (Organization Chart Diagram – OCh) практично не пов’язана з IDEF0 та ін методичними фрагментами ФМ. Це не дозволяє створити специфікації посадових обов’язків на основі цієї функціональної моделі – безпосередньо за допомогою інструментарію генерації звітів (Reports) по ній.


У розділі 6.3 «Генерація специфікацій посадових обов’язків (ДО)» [1], докладно розглянута процедура створення такої специфікації на основі індексації Mechanism Names подмассіва стрілок (Arrows), що представляють Roles в Organization Chart. Індексація тут дозволяє виділити масив Mechanism Arrows, що представляють (замінюють) Roles, з Arrow Dictionary і спростити подальшу роботу.


Крім розглянутого «технологічного» варіанту розробки посадової інструкції, ця ж задача може бути виконана трохи інакше. Розглянутий тут варіант надає деякі переваги перед згаданим вище.


Після завершення розробки функціональної моделі системи, для співробітників якої повинні бути створені посадові інструкції, створюється заготівля «технологічної» ФМ, призначеної виключно для створення специфікацій посадових обов’язків. Вона повинна бути копією розробленої ФМ з Arrow Dictionary звільненим від Mechanism Names. Це звільнення може бути здійснено тільки в одному варіанті – Видалити всі стрілки Mechanism з діаграм моделі і потім очистити словник в технології Merge Dictionary.


Для прискорення цієї невдячної роботи слід скористатися можливістю видалення відразу декількох стрілок, виділених Лассо. Це дозволяє одночасно видаляти всі механізми кожної Activity і кілька полегшує і прискорює роботу.


Після того, як механізми видалені, модель перетворилася в логічну ФМ.


Повністю уникнути роботи звільнення словника можна дещо змінивши план робіт. У передбаченні серйозною, а може бути і виключної (коли ФМ створюється з єдиною метою розробки ДО) роботи по створення специфікацій ДО співробітників слід розробляти цю ФМ як логічну, повністю уникаючи вказівки небудь механізмів.


Може виявитися, однак, що повністю виключити введення-механізмів не вдасться – з тієї причини, що без них буде утруднено коректне формування ФМ в якихось її фрагментах. В цьому випадку робота з очищення Arrow Dictionary, тим не менш, буде значно скорочена.


Так чи інакше, після звільнення Arrow Dictionary, слід імпортувати в нього імена посад з Role Dictionary (RD).


Коректно здійснюючи завдання генерації специфікацій посадових обов’язків, Role Dictionary і попередній йому Role Group Dictionary створюються в процесі розробки Organization Chart, що передує розробці посадових інструкцій.


Для імпорту інформації Role Dictionary відкриваємо його (див. рис. 1) і вибираємо Export.



Рис.1. Role Dictionary.

Проходимо без втручання вікно Step 1, Далі>. У вікні Step 2 (рис. 2)


  
 

Рис. 2. Вікно Step 2.


Рис. 3. Вікно Step 2. Пересилання колонок Role Group і Importance з Shown Column – в Hidden Column за допомогою << Remove.


переміщаємо колонки Role Group і Importance з Shown Column – в Hidden Column за допомогою << Remove (див. рис. 3) і залишаємо, таким чином, для експорту тільки дві колонки Name & Definition, що збігаються з колонками Arrow Dictionary.


По кнопці Готово зберегти експортований словник в *. CSV форматі.


Далі відкриваємо Arrow Dictionary (звільнений від Mechanism Name) і експортуємо в нього відредагований RD. В результаті отримуємо Arrow Dictionary, що поглинув наповнення колонки Name і колонки Definition словника Role Dictionary – див рис. 4 ..

Рис. 5. Реквізит Role в контекстному меню Activity.


Аналогічним чином можна згенерувати специфікації функцій підрозділів (Role Group) або згенерувати специфікації функцій фізичних осіб в системі (Resources – в термінології AllFusion Process Modeler).


Література


В.І. Дубейковскій. Ефективне моделювання з AllFusion Process Modeler 4.1.4 і AllFusion PM. Москва. ДІАЛОГ-МИФИ. 2007.



[1] Джерело – див http://www.1001.net.ua/.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*