Опис стандарту IDEF0

В даний час в Росії різко зріс інтерес до загальноприйнятих на Заході стандартам менеджменту, проте, у реальній практиці управління існує один дуже показовий момент. Багатьох керівників до досі можна поставити в глухий кут прямим питанням про організаційну структуру компанії або про схему існуючих бізнес-процесів. Найбільш просунуті і регулярно читають економічну періодику менеджери, як правило, починають креслити зрозумілі тільки їм одним ієрархічні діаграми, але і в цьому процесі зазвичай швидко заходять у глухий кут. Те ж саме стосується працівників та керівників різних служб і функціональних підрозділів. У більшості випадків, єдиним набором викладених правил, відповідно до яких має функціонувати підприємство, є набір окремих положень і посадових інструкцій. Найчастіше ці документи складалися не один рік тому, слабко структуровані і невзаімосвязанние між собою і, внаслідок цього, просто припадають пилом на полицях. До пори до часу подібний підхід був виправданий, тому що під час становлення російської ринкової економіки поняття конкуренції практично було відсутнє, та й витрати рахувати не було особливої необхідності – прибуток був гігантською. У результаті цього, ми бачимо протягом останніх двох років цілком зрозумілу картину: великі компанії, які виросли на початку 90-х років, поступово здають свої позиції, аж до повного виходу з ринку. Частково це обумовлено тим, що на підприємстві не були впроваджені стандарти управління, повністю було відсутнє поняття функціональної моделі діяльності й місії. За допомогою моделювання різних областей діяльності можна досить ефективно аналізувати "вузькі місця" в управлінні та оптимізувати загальну схему бізнесу. Але, як відомо, на будь-якому підприємстві вищий пріоритет мають тільки ті проекти, які безпосередньо приносять прибуток, тому мова про обстеження діяльності та її реорганізації зазвичай іде лише під час відчутного кризи в управлінні компанією.


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


Саме ж поняття "моделювання бізнес-процесів" прийшло в побут більшості аналітиків одночасно з появою на ринку складних програмних продуктів, призначених для комплексної автоматизації управління підприємством. Подібні системи завжди розуміють проведення глибокого передпроектного обстеження діяльності компанії. Результатом цього обстеження є експертний висновок, в якому окремими пунктами виносяться рекомендації щодо усунення "вузьких місць" в управлінні діяльністю. На підставі цього висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана реорганізація бізнес-процесів, іноді досить серйозна і болюча для компанії. Це і природно, що склався роками колектив завжди складно змусити "думати по-новому". Подібні комплексні обстеження підприємств завжди є складними і істотно відрізняються від випадку до випадку завданнями. Для вирішення подібних завдань моделювання складних систем існують добре обкатані методології і стандарти. До таких стандартів відносяться методології сімейства IDEF. З їх допомогою можна ефективно відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними. На даний момент до сімейства IDEF можна віднести такі стандарти:


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


IDEF1 – методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру та взаємозв'язку;


IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій "Сутність-взаємозв'язок" (ER – Entity-Relationship) та, як правило, використовується для моделювання реляційних баз даних, що мають відношення до даної системи;


IDEF2 – методологія динамічного моделювання розвитку систем. У зв'язку з дуже серйозними труднощами аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток призупинився на самому початковому етапі. Проте в даний час присутні алгоритми та їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані на базі "Розфарбованих мереж Петрі" (CPN – Color Petri Nets);


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


IDEF4 – методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів і закладені принципи їх взаємодії, тим самим дозволяючи аналізувати і оптимізувати складні об'єктно-орієнтовані системи;


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


Історія виникнення IDEF0


Методологію IDEF0 можна вважати наступним етапом розвитку добре відомого графічного мови опису функціональних систем SADT (Structured Analysis and Design Teqnique). Кілька років тому в Росії невеликим тиражем вийшла однойменна книга, що присвячує опису основних принципів побудови SADT-діаграм. Історично, IDEF0, як стандарт був розроблений в 1981 році в рамках широкої програми автоматизації промислових підприємств, яка носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом військово-повітряних сил США. Сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF = ICAM DEFinition). У процесі практичної реалізації, учасники програми ICAM зіштовхнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому крім покращеного набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках "аналітик-спеціаліст". Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.


В результаті пошуку відповідних рішень народилась методологія функціонального моделювання IDEF0. C 1981 року в стандарт IDEF0 були кілька незначних зміни, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 року Національним Інститутом із стандартизації і Технологій США (NIST).


Основні елементи і поняття IDEF0


Графічний мова IDEF0 дивно простий і гармонійний. В основі методології лежать чотири основні поняття.


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


Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:


  • Верхня сторона має значення "Управління" (Control);

  • Ліва сторона має значення "Вхід" (Input);

  • Права сторона має значення "Вихід" (Output);

  • Нижня сторона має значення "Механізм" (Mechanism).

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



    Малюнок 1. Функціональний блок.


    Другим "китом" методології IDEF0 є поняття інтерфейсної дуги (Arrow). Також інтерфейсні дуги часто називають потоками або стрілками. Інтерфейсна дуга відображає елемент системи, який обробляється функціональним блоком або надає інший вплив на функцію, відображену даними функціональним блоком.


    Графічним відображенням інтерфейсної дуги є односпрямована стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування повинне бути обігом іменника.


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


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


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


    При побудові IDEF0 – діаграм важливо правильно відокремлювати входять інтерфейсні дуги від керуючих, що часто буває непросто. Наприклад, на малюнку 2 зображено функціональний блок "Опрацювати заготовку".


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



    Малюнок 2.


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



    Малюнок 3.


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


    Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).


    Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.


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


    Модель IDEF0 завжди починається з представлення системи як єдиного цілого – одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою, і позначається ідентифікатором "А-0".


    У пояснювальному тексті до контекстної діаграмі повинна бути зазначена мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).


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


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


    У процесі декомпозиції, функціональний блок, який в контекстній діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Отримана діаграма другого рівня містить функціональні блоки, що відображають головні підфункції функціонального блоку контекстної діаграми і називається дочірньої (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірньої діаграмі відповідно називається дочірнім блоком – Child Box). У свою чергу, функціональний блок – предок називається батьківським блоком по відношенню до дочірньої діаграмі (Parent Box), а діаграма, до якої він належить – батьківської діаграмою (Parent Diagram). Кожна з підфункцій дочірньої діаграми може бути далі деталізована шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному разі декомпозиції функціонального блоку все інтерфейсні дуги, що входять у цей блок, або виходять з нього фіксуються на дочірній діаграмі. Цим досягається структурна цілісність IDEF0 – моделі. Наочно принцип декомпозиції представлений на рисунку 4. Слід звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм – кожен блок має свій унікальний порядковий номер на діаграмі (цифра у правому нижньому куті прямокутника), а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми. Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.


    Часто бувають випадки, коли окремі інтерфейсні дуги не має сенсу продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії, або навпаки – окремі дуги не мають практичного сенсу вище якогось рівня. Наприклад, інтерфейсну дугу, що зображає "деталь" на вході в функціональний блок "Опрацювати на токарному верстаті" не має сенсу відображати на діаграмах більше високих рівнів – це буде тільки перевантажувати діаграми і робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих "концептуальних" інтерфейсних дуг і не деталізувати їх глибше деякого рівня. Для вирішення подібних завдань у стандарті IDEF0 передбачено поняття тунелювання. Позначення "тунеля" (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги позначає, що ця дуга не була успадкована від функціонального батьківського блоку і з'явилася (з "тунелю") тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку – приймача означає той факт, що в дочірньою по відношенню до цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти та відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії – в такому випадку, вони спочатку "занурюються в тунель", а потім, при необхідності "Повертаються з тунелю".


    Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт передбачає створення та підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даним елементом. Цей набір називається глосарієм і є описом суті цього елемента. Наприклад, для керуючої інтерфейсної дуги "розпорядження про оплату" глосарій може містити перелік полів відповідного дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочний графічний мову, забезпечуючи діаграми необхідної додаткової інформацією.



    Малюнок 4. Декомпозиція функціональних блоків.


    Принципи обмеження складності IDEF0-діаграм


    Зазвичай IDEF0-моделі несуть в собі складну і концентровану інформацію, і для того, щоб обмежити їх перевантаженість і зробити легкими для читання, у відповідному стандарті прийняті відповідні обмеження Складність:


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


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


    Дисципліна групової роботи над розробкою IDEF0-моделі


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


    Створення моделі групою фахівців, що відносяться до різних сфер діяльності підприємства. Ця група в термінах IDEF0 називається авторами (Authors). Побудова початкової моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів і результатів опитувань створюється чернетка (Model Draft) моделі.


    Поширення чернетки для розгляду, узгоджень та коментарів. На цій стадії відбувається обговорення чернетки моделі з широким спектром компетентних осіб (в термінах IDEF0-читачів) на підприємстві. При цьому кожна з діаграм чорновий моделі письмово критикується і коментується, а потім передається автору. Автор, у свою чергу, також письмово погоджується з критикою чи відкидає її з викладом логіки ухвалення рішення і знову повертає відкоригований чернетку для подальшого розгляду. Цей цикл продовжується до тих пір, поки автори і читачі не прийдуть до єдиної думки.


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


    Особливості національної практики застосування функціонального моделювання засобами IDEF0


    В останні роки інтерес в Росії до методологій сімейства IDEF неухильно зростає. Це я постійно спостерігаю, переглядаючи статистику звернень до своєї персональної web-сторінці (http://www.vernikov.ru), на якій коротко описані основні принципи цих стандартів. При цьому інтерес до таких стандартів, як IDEF3-5 я б назвав теоретичним, а до IDEF0 цілком практично обгрунтованим. Власне кажучи, перші Case-засоби, що дозволяють будувати DFD та IDEF0 діаграми з'явилися на російське ринку ще в 1996 році, одночасно з виходом популярної книги за принципами моделювання в стандартах SADT.


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


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


    При проведенні складних проектів обстеження підприємств, розробка моделей в стандарті IDEF0 дозволяє наочно й ефективно відобразити весь механізм діяльності підприємства в потрібному розрізі. Однак найголовніше – це можливість колективної роботи, яку надає IDEF0. У моєї практичної діяльності було досить багато випадків, коли побудова моделі здійснювалося з прямою допомогою співробітників різних підрозділів. При цьому, консультант за досить короткий час пояснював їм основні принципи IDEF0 і навчав роботі з відповідним прикладним програмним забезпеченням. У результаті, співробітники різних відділів створювали IDEF-діаграми діяльності свого функціонального підрозділу, які повинні були відповісти на наступні питання:


    Що надходить до підрозділу "на вході"?


    Які функції, і в якій послідовності виконуються в рамках підрозділу?


    Хто є відповідальним за виконання кожної з функцій?


    Чим керується виконавець при виконанні кожної з функцій?


    Що є результатом роботи підрозділу (на виході)?


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


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


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

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


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

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

    Ваш отзыв

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

    *

    *