Як перетворити посадові інструкції з формальних документів на діючий інструмент?
По-перше, навіщо це може знадобитись? Дійсно, посадова інструкція — обов'язковий кадровий документ, з точки зору українського законодавства, але ніхто не заважає створити його формально і використовувати лише в радикальних випадках (наприклад, коли суперечки між працівниками і роботодавцем доходять до суду).
З іншого боку, для багатьох виконавців в будь-якому випадку потрібні конкретні інструкції та описи процедур і регламентів, тому може бути доцільно з самого початку створювати їх і як додаток до формального документу, посадової інструкції, що виписаний в загальному вигляді, і як максимально гнучкий та наближений до реальних задач інструмент, що використовується в повсякденній роботі.
Далі на гіпотетичному прикладі зробимо опис простої процедури з допомогою Bizagi modeler — програмі для створення діаграм бізнес-процесів в сучасній нотації BPMN.
Уявімо, що у нас є посадова інструкція для секретаря (або офіс-менеджера), там все виписано в загальному вигляді, в тому числі посадові обов'язки.
Опишемо процедуру прийома дзвінка, але попередньо — навіщо вона нам може знадобитись?
Можливі варіанти:
- для ознайомлення новачків;
- для визначення порядку дій та відповідальності;
- для подальшого аналізу та можливої оптимізації.
Для досвіченого помічника цінність такої процедури мінімальна, якщо взагалі є, але пам'ятаємо, наша ціль — не описати реальну процедуру, а просто на прикладі показати, як це можна зробити.
Отже,
1. Завантажуємо та встановлюємо Bizagi modeler. Він безкоштовний, але потребує реєстрації. Також там буде запропоновано деякі платні опції — на даному етапі доцільно від них поки що відмовитись.
2. Запускаємо, там буде приблизно таке:
В свій екаунт можна, насправді, і не заходити, просто закрити вікно.
3. Моделер використовується для опису процесів, але хай це вас не бентежить. Переіменовуємо назву процессу на, наприклад, "Прийняти вхідний дзвінок". Це можна зробити або подвійним кліком на назві процесу, або вибрати edit text правою кнопкою.
При цьому, назву процесу краще робити дієсловом з додатком, тобто "прийняти дзвінок", а не "прийом дзвінка". Чому? Тому що так виходить більш визначено.
4. Весь цей прямокутник називається "пул" ("басейн"). Якщо у нас виконавців буде більше одного, або один, але ми хочемо його явно визначити, то добавимо в наш "басейн" "доріжку" — виберемо її в палітрі зліва і просто перетягнемо її в "пул".
Доріжка представляє роль, виконавця. Тому назвемо її, наприклад, "секретар".
5. Наша процедура "запускається" певною стартовою подією, в нашому випадку — вхідним дзвінком. Стартові події в нотації BPMN позначаються колами з тонкої лінії:
Перетягуємо нашу стартову подію в пул на доріжку і називаємо її (також через подвійний клік) "вхідний дзвінок" (насправді, називати не обов'язково, але це дуже добра звичка і ознака професійного стилю):
6. Елементи в межах пулу з'єднуються стрілками з суцільної лінії і означають т. зв. передачу управління. Зараз у нас є стартова подія, вхідний дзвінок, далі нам треба визначити першу дію секретаря. Нехай це буде "прийняти дзвінок".
Важливе зауваження: якщо процес бажано називати дієсловом з додатком, але не обов'язково, то дію — обов'язково. Ніяких "прийом дзвінка". Виконавець повинен точно знати, що саме йому робити.
Клікаємо один раз на стартовій події (тобто "вибираємо" її), у нас буде приблизно таке:
Тобто навколо вибраного тами елементу з'явились варіанти-підказки інших елементів.
Нам лишилось просто вибрати потрібний і трохи "протягнути" його вправо, де йому місце.
Дії в BPMN позначаються закругленими прямокутниками:
Вибираємо його і "протягуємо" трохи вправо:
І переіменовуємо дію (також через подвійний клік на елементі) на "прийняти дзвінок":
Насправді, ми могли вибрати цей елемент в палітрі зліва, перетянути його, вибрати там потрібну стрілку з суцільної лінії, також перетягнути її, "приєднати" (в цьому моделері елементи "залипають" один до одного, коли їх з'єднувати).
Але ж погодьтесь — просто вибрати і протягнути набагато і простіше, і швидше, і зручніше.
Зауваження: ця дія у нас не просто "прийняти дзвінок". Насправді, секретар має привітатись, визначити хто дзвонить, з якою метою і т.д. Але ми все це напишемо пізніше, а поки що позначаємо дію максимально стисло і зрозуміло.
7. Припустимо, секретар тепер вже знає, хто і чого дзвонить, далі у нього вибір: відповісти самому чи перевести на іншого працівника офісу.
"Вибираємо" дію "прийняти дзвінок" (клікаємо один раз на об'єкті), далі з запропонованих варіантів вибираємо ромб, це т.зв. гейт:
Далі відразу "протягуємо" від гейту ще одну дію — наприклад, перевести дзвінок.
І відразу від цієї дії "протягуємо" червоний круг, це фінальна подія (позначається колом з жирною лінією). Її, як і стартову подію, можна не підписувати, але з огляду на професійний стиль краще це зробити. Назвемо її "дзвінок переведено":
8. Тепер нам треба позначити альтернативний варіант, коли секретар сам відповідає на дзвінок.
Для простоти в деталі вдаватись не будемо, просто введемо "надати відповідь самостійно" і також завершимо фінальною подією, яку назвем "відповідь надано".
Для цього знову клікаємо на символі гейту:
Знову вибираємо нову дію, тільки протягуємо її не вправо, там місця вже нема, а вниз:
І завершуємо фінальною подією:
9. На довершення підпишемо ще гейт, поставимо там запитання "треба перевести дзвінок?"
Для цього два раза клікнемо на ньому і підпишемо. Для зручності один раз клікнемо на самому підписі і "витягнемо" його нагору, щоб він не заважав.
Потім два раза клікнемо по черзі на вихідних стрілках з гейту і підпишемо їх відповідно "так" та "ні":
Все, сама діаграма готова.
Нагадую, у нас нема задачі описати процедуру точно, це просто приклад, щоб зрозуміти, як це можна зробити.
10. У нас є діаграма, але це ще не інструкція. Не вистачає більш докладного опису дій.
Для початку доповнимо деталями дію "прийняти дзвінок". Для цього клікнемо на ній правою кнопкою і виберемо з меню властивості, properties:
Далі в полі Description (опис) ми можемо детально описати дію.
Давайте напишемо, наприклад, таке: "Прийняти дзвінок, уточнити, хто дзвонить, з якою метою, чи були попередні домовленності і т.і."
В цьому полі, насправді, можна написати досить багато тексту. І саме тому не варто перевантажувати надпис на самому символі дії — деталі краще описани в властивостях.
Добавимо також, для прикладу, описи і в інші дії. В "перевести дзвінок" напишемо "За потреби перевести дзвінок на потрібного спеціаліста, перед цим його попередивши".
В дію "Надати відповідь самостійно" напишемо "Якщо дзвінок не потребує переводу на іншого спеціаліста, надати відповідь самойстійно, згідно з інформаційною політикою компанії".
11. Тепер давайте збережемо наш файл, для цього вибираємо потрібний пункт в меню або просто одночасно нажимаємо Ctrl+s, далі вибираємо збереження на комп'ютері і нажимаємо Save (зберегти як collaboration file може бути в платному варіанті):
12. Тепер у нас є файл в "рідному" для моделера форматі, але щоб його, наприклад, ще раз переглянути, потрібно, щоб на комп'ютері був встановлений цей моделер.
Це не зручно, тому що переважній більшості працівників ця програма не потрібна, тому представимо опис в іншому форматі.
Для цього "опублікуємо" процедуру: жмемо на пункт меню Publish, вибираємо формат PDF:
Далі програма пропонує вибрати для публікації діаграми. У нас одна діаграма, її і вибираємо:
Жмемо на кнопку Next, нам показують всі елементи, які можуть увійти до публікації. Нам вони всі не потрібні, тому вибираємо закладку Tasks (задачі):
І зразу вибираємо всі задачі (переносимо їх кнопкою вправо):
І знову жмемо Next:
Далі вибираємо тип подачі документу, ландшафтне чи портретне, розміщення вихідного файлу і т.і., і жмемо на Finish:
І Bizagi Modeler сформує нам документ у форматі pdf
... де буде автоматично сформований зміст (при цьому пункти змісту — діючі лінки на відповідні розділи):
Документ, звісно, буде містити нашу діаграму:
А також опис дій, де буде автоматично включено той самий детальний текст, який ми вносили у властивості до відповідних елементів (дій):
Резюме.
Таким чином, ми на дуже спрощеному прикладі продемонстрували як зробити додаток до службової інструкції у вигляді опису конкретної процедури.
При цьому, опис у нас вийшов з одного боку дуже наочний, візуалізований через інтуїтивно зрозумілу діаграму, а з іншого — настільки детальний, наскільки ми того захочемо.
І все це можна досить швидко і зручно вигрузити-опублікувати в один документ.
Кілька доповнень:
1) як було вказано вище, даний приклад дуже спрощено — ціль була продемонструвати деякі можливості моделера, а не скласти актуальний опис процедури;
2) в нашому випадку всю процедуру виконує один виконавець — але в межах одного пулу може бути кілька виконавців;
3) при цьому різним виконавцям на різних етапах можна присвоювати різну ступінь відповідальності за схемою RACI; але цю та інші корисні можливості ми не розглядали, щоб не перевантажувати і без того довгий текст;
4) даний документ не може слугувати заміною службової інструкції, але може дуже доречно її доповнити і перетворити з бездушного документа на робочий інструмент;
5) більш складні описи процедур і процесів виконують дуже важливу роль координації роботи різних виконавців, тут це не було описано ні в якому вигляді — ми можемо розглянути це в майбутньому;
6) звичка коректно регламентувати роботу — корисна і для керівників, і для виконавців, але корисно також пам'ятати, що регламенти не завжди доречні і навіть можливі, і дотримуватись принципів здорового глузду, не намагаючись зробити такі описи і регламенти, які не будуть використовуватись на практиці або які замість допомоги в координації будуть додатковами перешкодами.
Якщо потрібні консультації, ворк шопи, семінари чи тренінги — буду радий допомогти.
Дякую за увагу. ☺
По-перше, навіщо це може знадобитись? Дійсно, посадова інструкція — обов'язковий кадровий документ, з точки зору українського законодавства, але ніхто не заважає створити його формально і використовувати лише в радикальних випадках (наприклад, коли суперечки між працівниками і роботодавцем доходять до суду).
З іншого боку, для багатьох виконавців в будь-якому випадку потрібні конкретні інструкції та описи процедур і регламентів, тому може бути доцільно з самого початку створювати їх і як додаток до формального документу, посадової інструкції, що виписаний в загальному вигляді, і як максимально гнучкий та наближений до реальних задач інструмент, що використовується в повсякденній роботі.
Далі на гіпотетичному прикладі зробимо опис простої процедури з допомогою Bizagi modeler — програмі для створення діаграм бізнес-процесів в сучасній нотації BPMN.
Уявімо, що у нас є посадова інструкція для секретаря (або офіс-менеджера), там все виписано в загальному вигляді, в тому числі посадові обов'язки.
Опишемо процедуру прийома дзвінка, але попередньо — навіщо вона нам може знадобитись?
Можливі варіанти:
- для ознайомлення новачків;
- для визначення порядку дій та відповідальності;
- для подальшого аналізу та можливої оптимізації.
Для досвіченого помічника цінність такої процедури мінімальна, якщо взагалі є, але пам'ятаємо, наша ціль — не описати реальну процедуру, а просто на прикладі показати, як це можна зробити.
Отже,
1. Завантажуємо та встановлюємо Bizagi modeler. Він безкоштовний, але потребує реєстрації. Також там буде запропоновано деякі платні опції — на даному етапі доцільно від них поки що відмовитись.
2. Запускаємо, там буде приблизно таке:
В свій екаунт можна, насправді, і не заходити, просто закрити вікно.
3. Моделер використовується для опису процесів, але хай це вас не бентежить. Переіменовуємо назву процессу на, наприклад, "Прийняти вхідний дзвінок". Це можна зробити або подвійним кліком на назві процесу, або вибрати edit text правою кнопкою.
При цьому, назву процесу краще робити дієсловом з додатком, тобто "прийняти дзвінок", а не "прийом дзвінка". Чому? Тому що так виходить більш визначено.
4. Весь цей прямокутник називається "пул" ("басейн"). Якщо у нас виконавців буде більше одного, або один, але ми хочемо його явно визначити, то добавимо в наш "басейн" "доріжку" — виберемо її в палітрі зліва і просто перетягнемо її в "пул".
Доріжка представляє роль, виконавця. Тому назвемо її, наприклад, "секретар".
5. Наша процедура "запускається" певною стартовою подією, в нашому випадку — вхідним дзвінком. Стартові події в нотації BPMN позначаються колами з тонкої лінії:
Перетягуємо нашу стартову подію в пул на доріжку і називаємо її (також через подвійний клік) "вхідний дзвінок" (насправді, називати не обов'язково, але це дуже добра звичка і ознака професійного стилю):
6. Елементи в межах пулу з'єднуються стрілками з суцільної лінії і означають т. зв. передачу управління. Зараз у нас є стартова подія, вхідний дзвінок, далі нам треба визначити першу дію секретаря. Нехай це буде "прийняти дзвінок".
Важливе зауваження: якщо процес бажано називати дієсловом з додатком, але не обов'язково, то дію — обов'язково. Ніяких "прийом дзвінка". Виконавець повинен точно знати, що саме йому робити.
Клікаємо один раз на стартовій події (тобто "вибираємо" її), у нас буде приблизно таке:
Тобто навколо вибраного тами елементу з'явились варіанти-підказки інших елементів.
Нам лишилось просто вибрати потрібний і трохи "протягнути" його вправо, де йому місце.
Дії в BPMN позначаються закругленими прямокутниками:
Вибираємо його і "протягуємо" трохи вправо:
І переіменовуємо дію (також через подвійний клік на елементі) на "прийняти дзвінок":
Насправді, ми могли вибрати цей елемент в палітрі зліва, перетянути його, вибрати там потрібну стрілку з суцільної лінії, також перетягнути її, "приєднати" (в цьому моделері елементи "залипають" один до одного, коли їх з'єднувати).
Але ж погодьтесь — просто вибрати і протягнути набагато і простіше, і швидше, і зручніше.
Зауваження: ця дія у нас не просто "прийняти дзвінок". Насправді, секретар має привітатись, визначити хто дзвонить, з якою метою і т.д. Але ми все це напишемо пізніше, а поки що позначаємо дію максимально стисло і зрозуміло.
7. Припустимо, секретар тепер вже знає, хто і чого дзвонить, далі у нього вибір: відповісти самому чи перевести на іншого працівника офісу.
"Вибираємо" дію "прийняти дзвінок" (клікаємо один раз на об'єкті), далі з запропонованих варіантів вибираємо ромб, це т.зв. гейт:
І відразу від цієї дії "протягуємо" червоний круг, це фінальна подія (позначається колом з жирною лінією). Її, як і стартову подію, можна не підписувати, але з огляду на професійний стиль краще це зробити. Назвемо її "дзвінок переведено":
8. Тепер нам треба позначити альтернативний варіант, коли секретар сам відповідає на дзвінок.
Для простоти в деталі вдаватись не будемо, просто введемо "надати відповідь самостійно" і також завершимо фінальною подією, яку назвем "відповідь надано".
Для цього знову клікаємо на символі гейту:
Знову вибираємо нову дію, тільки протягуємо її не вправо, там місця вже нема, а вниз:
І завершуємо фінальною подією:
9. На довершення підпишемо ще гейт, поставимо там запитання "треба перевести дзвінок?"
Для цього два раза клікнемо на ньому і підпишемо. Для зручності один раз клікнемо на самому підписі і "витягнемо" його нагору, щоб він не заважав.
Потім два раза клікнемо по черзі на вихідних стрілках з гейту і підпишемо їх відповідно "так" та "ні":
Все, сама діаграма готова.
Нагадую, у нас нема задачі описати процедуру точно, це просто приклад, щоб зрозуміти, як це можна зробити.
10. У нас є діаграма, але це ще не інструкція. Не вистачає більш докладного опису дій.
Для початку доповнимо деталями дію "прийняти дзвінок". Для цього клікнемо на ній правою кнопкою і виберемо з меню властивості, properties:
Далі в полі Description (опис) ми можемо детально описати дію.
Давайте напишемо, наприклад, таке: "Прийняти дзвінок, уточнити, хто дзвонить, з якою метою, чи були попередні домовленності і т.і."
В цьому полі, насправді, можна написати досить багато тексту. І саме тому не варто перевантажувати надпис на самому символі дії — деталі краще описани в властивостях.
Добавимо також, для прикладу, описи і в інші дії. В "перевести дзвінок" напишемо "За потреби перевести дзвінок на потрібного спеціаліста, перед цим його попередивши".
В дію "Надати відповідь самостійно" напишемо "Якщо дзвінок не потребує переводу на іншого спеціаліста, надати відповідь самойстійно, згідно з інформаційною політикою компанії".
11. Тепер давайте збережемо наш файл, для цього вибираємо потрібний пункт в меню або просто одночасно нажимаємо Ctrl+s, далі вибираємо збереження на комп'ютері і нажимаємо Save (зберегти як collaboration file може бути в платному варіанті):
12. Тепер у нас є файл в "рідному" для моделера форматі, але щоб його, наприклад, ще раз переглянути, потрібно, щоб на комп'ютері був встановлений цей моделер.
Це не зручно, тому що переважній більшості працівників ця програма не потрібна, тому представимо опис в іншому форматі.
Для цього "опублікуємо" процедуру: жмемо на пункт меню Publish, вибираємо формат PDF:
Далі програма пропонує вибрати для публікації діаграми. У нас одна діаграма, її і вибираємо:
Жмемо на кнопку Next, нам показують всі елементи, які можуть увійти до публікації. Нам вони всі не потрібні, тому вибираємо закладку Tasks (задачі):
І зразу вибираємо всі задачі (переносимо їх кнопкою вправо):
І знову жмемо Next:
Далі вибираємо тип подачі документу, ландшафтне чи портретне, розміщення вихідного файлу і т.і., і жмемо на Finish:
І Bizagi Modeler сформує нам документ у форматі pdf
... де буде автоматично сформований зміст (при цьому пункти змісту — діючі лінки на відповідні розділи):
Документ, звісно, буде містити нашу діаграму:
А також опис дій, де буде автоматично включено той самий детальний текст, який ми вносили у властивості до відповідних елементів (дій):
Резюме.
Таким чином, ми на дуже спрощеному прикладі продемонстрували як зробити додаток до службової інструкції у вигляді опису конкретної процедури.
При цьому, опис у нас вийшов з одного боку дуже наочний, візуалізований через інтуїтивно зрозумілу діаграму, а з іншого — настільки детальний, наскільки ми того захочемо.
І все це можна досить швидко і зручно вигрузити-опублікувати в один документ.
Кілька доповнень:
1) як було вказано вище, даний приклад дуже спрощено — ціль була продемонструвати деякі можливості моделера, а не скласти актуальний опис процедури;
2) в нашому випадку всю процедуру виконує один виконавець — але в межах одного пулу може бути кілька виконавців;
3) при цьому різним виконавцям на різних етапах можна присвоювати різну ступінь відповідальності за схемою RACI; але цю та інші корисні можливості ми не розглядали, щоб не перевантажувати і без того довгий текст;
4) даний документ не може слугувати заміною службової інструкції, але може дуже доречно її доповнити і перетворити з бездушного документа на робочий інструмент;
5) більш складні описи процедур і процесів виконують дуже важливу роль координації роботи різних виконавців, тут це не було описано ні в якому вигляді — ми можемо розглянути це в майбутньому;
6) звичка коректно регламентувати роботу — корисна і для керівників, і для виконавців, але корисно також пам'ятати, що регламенти не завжди доречні і навіть можливі, і дотримуватись принципів здорового глузду, не намагаючись зробити такі описи і регламенти, які не будуть використовуватись на практиці або які замість допомоги в координації будуть додатковами перешкодами.
Якщо потрібні консультації, ворк шопи, семінари чи тренінги — буду радий допомогти.
Дякую за увагу. ☺

































No comments:
Post a Comment