Об'єкти

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


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


Різні постачальники засобів моделювання та консалтингові компанії використовують різну термінологію, що описує сукупність моделей процесів у рамках процесного підходу; різна термінологія застосовується і в різних проектах з опису бізнес-процесів. Як приклад наведемо ієрархію процесів, представлену в навчальному курсі "Методи та засоби управління бізнес-процесами" компанії "IDS Scheer Росія і країни СНД ":



При цьому коректним вважається такий підхід до моделювання, коли модель будь-якого рівня (крім верхнього) є деталізацією об'єкта будь-якої моделі попереднього рівня (такий підхід, зокрема, підтримується продуктами сімейства ARIS компанії IDS Scheer та інструментом AllFusion Process Modeler (BPwin) компанії Computer Associates). Деталізація – це умовний прийом, що дозволяє представити систему у вигляді, зручному для сприйняття та аналізу, і зробити моделі більш чіткими і зрозумілими (рис. 1).


Рис. 1. Деталізація об'єкта на модель наступного рівня


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


Рис. 2. Приклад моделі процесів верхнього рівня


Склад процесів верхнього рівня може бути різним, але в багатьох випадках при моделюванні дотримуються так званої 13-процесної моделі, створеної за даними Міжнародної бенчмаркінгового палати (International Benchmarking Clearinghouse), – див. рис. 2. Втім, існують і інші підходи до моделювання, в основі яких лежить інший спосіб визначення процесів верхнього рівня.


Різні типи моделей та їх взаємозв'язку


Відзначимо, що крім процесів моделюються і інші аспекти діяльності організації. Так, однією з традиційно використовуваних є модель організаційної структури (подібні моделі, накреслені тушшю на аркушах ватману, можна було побачити ще в 1970-80-х роках в багатьох радянських державних організаціях; сучасний вигляд моделі організаційної структури представлений на рис. 3).


Рис. 3. Приклади моделей організаційної структури

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


Нерідко одні й ті ж об'єкти можуть використовуватися в різних моделях. Так, на моделі процесу і на моделі оргструктури можуть бути присутніми одні й ті ж об'єкти (наприклад, виконавці функцій, виконуваних протягом процесу, – рис. 4).


Рис. 4. Приклад використання одного і того ж об'єкта на різних моделях


Загальні об'єкти можуть бути на моделі процесу і на моделі документів, на моделі інформаційних систем і на моделі процесу, на моделі оргструктури і на моделі повноважень і т.д.


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


Технічні аспекти реалізації взаємозв'язків моделей


Коли ми розглядаємо взаємозв'язку між моделями з допомогою деталізації об'єкту на іншу модель з логічної точки зору, то не повинні забувати про те, як реалізувати подібний взаємозв'язок технічно. Наприклад, якщо ми застосовуємо засіб моделювання, яке зберігає кожну модель у вигляді окремого файлу, то слід віддавати собі звіт в тому, що при деталізації об'єкту на модель потрібно десь зберігати посилання на файл (наприклад, в якомусь атрибуті об'єкта). Це означає, що засіб моделювання має як мінімум підтримувати атрибути, що дозволяють зберігати подібні дані, а ще краще – надавати настільки дружній інтерфейс, щоб по клацанню миші на подібному атрибуті засіб моделювання відкривало відповідний файл. Крім того, слід пам'ятати, що при перенесенні файлів з моделями в іншій каталог посилання на файли в атрибутах моделей можуть виявитися недійсними. Але ж при докладному описі діяльності підприємств число моделей цілком може бути чотиризначним … Іншими словами, проблема технічної підтримки в працездатному стані сукупності пов'язаних між собою таким чином моделей може виявитися досить серйозною.


Вирішити її дозволяє застосування засобу моделювання, яке дає можливість зберігати сукупність моделей як мінімум в єдиному файлі, а ще краще – в якій-небудь серверної СУБД з реалізацією багатокористувацького доступу та розмежуванням доступу до даних (адже чотиризначне число моделей, як правило, створює не одна особа). З доступних на ринку і поширених у Росії рішень до таких інструментів відносяться засоби моделювання сімейства ARIS і дорожчий набір інструментів AllFusion Modelling Suite (включає інструмент для колективної роботи над моделями ModelMart). Пропонуються також рішення на основі Visio, реалізують подібну функціональність, але створені вони не настільки відомими партнерами Microsoft, а тому не факт, що варто їх шукати, – через відсутність в Росії послуг з їх технічної підтримки і навчання роботі з ними.


Що таке "один і той самий об'єкт"?


Ще одна проблема реалізації взаємозв'язків полягає в чіткому визначенні, що таке "один і той самий об'єкт" при наявності одних і тих же об'єктів на різних моделях. Ця проблема набагато серйозніша, ніж організація посилань на файли в попередньому випадку. Перше що спадає на думку визначення поняття "один і той самий об'єкт" виглядає приблизно так: це об'єкти того ж типу (приміром, що відображаються однаковими символами або символами, які належать до однієї групи, – це залежить від того, як саме підтримується концепція типу об'єкта в засобі моделювання), що володіють однаковими назвами або, у разі підтримки засобом моделювання безлічі атрибутів, з однаковим набором атрибутів.


Якщо ми моделюємо діяльність одного підприємства, то об'єкт "головний бухгалтер" цілком може бути одним і тим же на різних моделях – як правило, головний бухгалтер на підприємстві один. Але, наприклад, чи є одним і тим же об'єкт "службова записка" на різних моделях? Автори різних моделей цілком можуть назвати одним і тим же словосполученням "службова записка" такі різні об'єкти, як службова записка на видачу грошей на відрядження та службова записка на надання автотранспорту, – адже вони мислять в обмежених рамках модельованого процесу, в якому цілком може фігурувати один-єдиний тип службової записки. А якщо повернутися до прикладу з об'єктом "головний бухгалтер", але моделювати діяльність не окремого підприємства, а холдингу? Очевидно, що головних бухгалтерів у холдингу буде як мінімум стільки ж, скільки підприємств входить до його складу.


Дана проблема, звичайно ж, може бути вирішена шляхом установки строгих правил іменування об'єктів і обмежень на значення їх атрибутів, а також строгого визначення, що таке "один і той самий об'єкт", – тобто організаційних, а не технічних рішень. Але є і ще одне рішення: зберігати опису об'єктів як бізнес-сутностей окремо від моделей, у той час як на самі моделі розміщувати посилання на ці описи. З доступних на російському ринку засобів моделювання, мабуть, подібної особливістю зберігання даних сьогодні володіє тільки ARIS (під словосполученням "доступний" я маю на увазі продукт, забезпечений в Росії передпродажними консультаціями, технічною підтримкою і навчанням російською мовою) – це рішення підтримує концепцію визначення об'єктів і зв'язків як елементів даних, що містять відомості про тип об'єкта, назві, атрибутах, і примірників об'єктів, що містять відомості про символ, його кольорі, розмірі, місцезнаходження, товщині ліній, шрифту написів – тобто про візуальні характеристики відображення на моделі.


Втім, з вищевикладеного аж ніяк не випливає, що ARIS – це панацея від всіх бід і саме той засіб моделювання, яке потрібно всім і завжди. Ще раз повторю: вибір засоби моделювання залежить від його цілей і завдань. Якщо потрібна одна модель – її можна намалювати ручкою на папері, якщо потрібно п'ять моделей (навіть пов'язаних між собою) – підійде будь-який засіб моделювання, що підтримує потрібну для рішення поставленої задачі нотацію (наприклад, найдешевша версія Visio або який-небудь безкоштовний інструмент типу Borland Together Designer). А от якщо моделей кілька сотень – вибір інструменту моделювання повинен бути ретельно, оскільки наслідки неправильного рішення, як показує практика, обходяться компаніям дуже дорого.

 

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


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

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

Ваш отзыв

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

*

*