Cтиль ERP-проекту

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


Спробуємо знайти закономірність в управлінні саме «неправильними» проектами, що є не кращу, а реальну практику (на прикладі проектів впровадження ERP-систем).

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

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

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

Конфігурації бізнесу

Прикладом вдалої систематизації стійких форм організації (в бізнесі) є теорія конфігурацій бізнесу, розроблена Генрі Мінцберга [1] і заснована на класифікації механізмів координації людей при спільній роботі. У сучасних бізнес-організаціях Мінцберг виділив п'ять домінуючих типів таких механізмів: «прямий контроль»(Робота за прямими дорученнями, безпосереднє управління діями персоналу),«стандартизація операцій»(Робота за інструкціями в рамках бізнес-процесів, управління не людьми, а правилами і процедурами, за якими вони працюють),«стандартизація кваліфікації»(Робота, заснована на професійному мистецтві фахівців, управління призначенням або зміщенням з посади, контролюється тільки кваліфікація персоналу),«взаємне узгодження»(Колективна робота, керування у вигляді уточнення та узгодження вимог до результатів, умов чи учасникам якогось унікального робочого процесу),«стандартизація випуску»(Робота по досягненню заданого результату, управління у вигляді визначення та узгодження планів випуску та забезпечення ресурсами).

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

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

Мінцберг виділив п'ять конфігурацій [1], описав їх і визначив умови їх виживання. На Рис.1 наведено області стійкого існування конфігурацій бізнесу (у системі координат так званого квадрата невизначеності).


Рис.1. Області стійкого існування конфігурацій бізнесу.

Для бізнесу на ринку ІТ можна привести наступні реальні приклади перерахованих конфігурацій: «проста конфігурація» – одноразові «коробкові» продажу, «механістична бюрократія» – дистрибуція програмного і апаратного забезпечення, «професійна бюрократія» – навчання і технічна підтримка, «адхократии» – замовні унікальні розробки, інтеграційні проекти або впровадження великих інтегрованих систем, «дивізіональна конфігурація» – комплексні продажу в рамках великого системного інтегратора. Аналогічний повний набір конфігурацій можна знайти в будь-якій галузі.

Стилі ІТ-проекту

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

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

Області управління ІТ-проектом

Більшість стандартів з управління проектами [3,4] описують точку зору на проект тільки одного з його ключових учасників, а саме керівника проекту. Однак існують і інші ключові учасники, предмет діяльності і сферу відповідальності яких виходять за межі реальних повноважень керівника проекту. До них відносяться архітектор1 (Головний інженер) та спонсор2(Директор) проекту.

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

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

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

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

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

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

Описані нижче стилі можуть зустрічатися при впровадженні не тільки однієї і тієї ж ERP-системи, але навіть і в проектах одного інтегратора.




























Політичний проект

Домінуючий механізм координації – робота за прямими дорученнями

Управління впровадженням

Управління проектом

Управління контрактом

Стратегія впровадження – «Натягування системи на існуючий бізнес». Рішення приймаються одним лідером – всі інші працюють за його дорученнями. Головну роль відіграє спонсор проекту, керівник проекту грає технічну роль. Диктат замовника виражається формулою «Ми вам платимо – ви нам робите». Статус управління проектом низький.
Вимоги слабо узгоджені і сильно мінливі. Вони більшою мірою відображають не стратегію бізнесу, а внутрішню кон'юнктуру відносин підрозділів замовника. Планування і контроль термінів і витрат носить узагальнений характер. Головна проблема – утримати межі і статус управління проектом. Предмет контракту визначено в загальних рисах. Вся конкретика зобов'язань міститься в особистих домовленостях спонсорів (з боку підрядника він, як правило, з числа перших осіб).
Великий обсяг додаткових розробок, який не рідко спотворює інтеграційну схему придбаної ERP-системи. Це в свою чергу, іноді призводить до серйозних проблем з технічною підтримкою. Проектна група – згуртована команда добре знайомих і лояльних учасників (друзів). Усі працюють з повним завантаженням на проекті. Формально домінуючим типом контракту є «Фіксована ціна і терміни», але фактична його реалізація у вигляді додаткових угод, знижок і премій робить його схожим на тип контракту, званий у світовій практиці «оплата фактичних витрат + додаткові витрати».
Підсумкова архітектура одержуваного рішення схожа на «клаптева ковдра», яке є дзеркалом кон'юнктури внутрішніх відносин замовника. Домінують неформальні персоналізовані комунікації, засновані на міжособистісних відносинах «своїх». Слабке документування проекту. Підрядник орієнтований на підтримку безперервності відносин, яка йому забезпечує безперервність грошового потоку. Сильна залежність від особистих відносин і слабкий контроль витрат і термінів часто виводять проект підрядника на межу рентабельності. Для замовника впровадження ERP-системи в цьому стилі, як правило, призводить до лише окремої локальної оптимізації зі слабко виділяються бізнес ефектами.
Типовим сценарієм потрапляння проекту в такий стиль є такий вибір замовником світового виробника ERP-системи, при якому компанія-інтегратор є «бідним родичем». У цьому випадку виразно проявляється закон переговорів «Домовляються тільки рівні. Нерівні шикуються у вертикаль ».


























Типовий проект

Домінуючий механізм координації – робота за інструкціями

Управління впровадженням

Управління проектом

Управління контрактом

Стратегія впровадження – «Конвеєр: установка, стандартні налаштування, стандартне навчання».

Вся діяльність регламентована процедурами. Рішення приймаються різними учасниками у відповідність із заздалегідь визначеними повноваженнями. Розвинена управлінська спеціалізація: спонсори (замовник – керівник функціонального підрозділу або ІТ служби, підрядник – менеджер з продажу), керівник – технічний планувальник, координатор і адміністратор проекту.

Диктат замовника виражається формулою «Якщо щось не так, то он чергу стоїть». Проекти легко починаються і легко зупиняються. Статус управління проектом низький.

Вимоги зумовлені системою і приймаються замовником на етапі її придбання.

Детальне планування і контроль термінів і витрат. Головна проблема – утримати межі проекту та скоординувати ресурси.

Предмет контракту – постачання програмного, апаратного забезпечення та послуг. Контракт – це детальний план поставки.

Детально опрацьована технологія впровадження. Всі додаткові розробки проводяться поза рамками проекту.

Проектна група схожа на механізм з «людськими ресурсами», для якого характерна вузька спеціалізація. Всі учасники, в тому числі і керівник проекту, можуть бути одночасно задіяні в декількох аналогічних проектах.

Домінуючим реальним типом контракту є «Фіксована ціна і терміни». В умовах жорсткої конкуренції між виробниками і інтеграторами типовим механізмом їх вибору є тендер.

Підсумкова архітектура – стандартне коробкове локальне бізнес додаток.

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

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

Типовим прикладом такого стилю можна вважати запровадження окремого модуля ERP-системи в окремо взятому підрозділі з добре стандартизованими бізнес процесами. У рамках даного стилю також можуть розгортатися типові проекти тиражування в підрозділах великого підприємства впровадженого прототипу великий ERP-системи.




























Професійний проект

Домінуючий механізм координації – робота, заснована на професійному мистецтві фахівців

Управління впровадженням

Управління проектом

Управління контрактом

Стратегія впровадження – «Бізнес замовника натягують на систему». Координація професіоналів з дуже високою кваліфікацією і досвідом. Ключова роль архітектора. Той, хто в змозі утримувати цілісну картину бізнесу та інтеграції системи, той реально приймає рішення. Диктат підрядника (інтегратора) виражається формулою «Хочете кращу практику, шикуйтеся». Статус управління проектом високий. Це можливо тільки при сильному бренді підрядника як консультанта.
Вимоги визначені моделями «кращої практики», «зашитими» в систему. Детальне планування і контроль термінів і витрат. Предмет контракту – найм або сервіс команди професіоналів.
Детально опрацьована технологія впровадження, орієнтована на впровадження моделей «кращої практики». Всі додаткові розробки зводяться до мінімуму або проводяться поза рамками проекту. Проектна група це команда професіоналів з широкою кваліфікацією, яка має великий експертної владою. Це створює сильну залежність від цієї групи в ході проекту, так і в ході експлуатації системи замовником після проекту. Професіоналам властивий індивідуалізм, що створює проблеми стійкості проектної групи. Повна зайнятість усіх учасників на проекті. Головна проблема замовника – встигнути створити в ході проекту свою аналогічну команду професіоналів і потім її утримати. Домінуючим реальним типом контракту є «Оплата часу за тарифами». Навіть тоді, коли контракт формально виявляється іншого типу, наприклад, «Фіксована ціна і терміни», реальна практика його виконання спирається на заздалегідь обумовлені тарифи. Чим сильніше бренд, тим вище тарифи.
Підсумкова архітектура – сильно інтегрована корпоративна система управління бізнесом. У групі між професіоналами непрозорі міжособистісні комунікації. По відношенню до зовнішніх учасникам проекту комунікації формалізовані і добре документовані. Проекти добре документуються. Підрядник дістає прибуток з бренду і високої кваліфікації своїх професіоналів. Замовник отримує в своєму бізнесі реалізацію моделей «кращої практики», яка при вмілому використанні може дати йому конкурентні переваги.
Проекти в цьому стилі є ідеалом всіх великих світових консалтингових компаній. Всі проекти, що відхиляються від цього стилю, ними передаються місцевим партнерам. Даний стиль цілком адекватний для тих замовників, бізнес стратегією яких є вихід на рівень світових стандартів з наступним його практичним підтвердженням.


























Інноваційний проект

Домінуючий механізм координації – взаємне узгодження

Управління впровадженням

Управління проектом

Управління контрактом

Стратегія впровадження – «Впровадження системи – це локомотив перетворень в бізнесі». Спільне прийняття рішень в умовах жорсткої невизначеності. Розподіл відповідальності за результати. Замовник і підрядник – рівноправні партнери. Статус управління проектом максимально високий. Це можливо тільки при довгостроковому стратегічному партнерстві між ними.
Вимоги є компромісом між можливостями системи та потребами бізнесу замовника, визначеними в його бізнес-стратегії. Планування проекту в контексті бізнес-стратегії. Головна проблема – утримати стратегічні бізнес орієнтири. Предмет контракту – стратегічне партнерство, альянс
Технологія впровадження допускає ітераційний процес проб і помилок. Велике значення має технологія керування вимогами і тестуванням, а також контроль бізнес ефектів. Великий обсяг додаткових розробок. Проектна група це команда першопрохідців. Універсальність кваліфікації. Головна компетенція членів проектної групи – командна робота і здатність вчитися на помилках. Командний дух з сильною прихильністю стратегічним цілям бізнесу. Повна зайнятість у проекті. Контракт представляє собою рамкову угоду, в якому визначаються джерела формування бізнес ефектів і принципи поділу ризиків, а також принципи організації спільної роботи.
Підсумкова архітектура – це оболонка для підтримки і перетворень бізнесу. Велике значення мають технології групової роботи, здатні одночасно підтримувати неформальні комунікації і формалізоване документування дій. Єдине комунікаційне та інформаційний простір проекту є найважливішим активом проекту. Витяг прибутку кожним з учасників проекту як із спільного підприємства за рахунок отримання своїх ефектів. Саме на таких проектах інтегратори вириваються в лідери, а замовники реалізують системні інновації. Саме ці проекти з точки зору регулярного бізнесу є найбільш ризикованими. Проект даного стилю породжує проекти в суміжних областях, які, як правило, групуються в єдину бізнес програму.
Даний стиль цілком адекватний для тих замовників, бізнес стратегією яких є лідерство у певній ніші. Основою такого лідерства є унікальність бізнес моделі створення доданої вартості. Прикладом такого проекту може бути випадок, коли замовник розробив стратегію лідерства в певній ніші ринку і прийняв рішення, що ERP-система може суттєво в цьому допомогти, ініціюючи системні зміни бізнесу і фіксуючи нову бізнес модель. Тим більше що на ERP ринку з'явився новий модуль, орієнтований саме на цю нішу. З іншого боку, інтегратор пов'язав свою бізнес стратегію з цим новим модулем, з яким ще по-серйозному ніхто не працював. Вони знайдуть один одного як партнери.
На жаль, приклади реалізації таких проектів у російській практиці вкрай рідкісні. Тим не менш, у західній практиці є не тільки прецеденти, а й навіть школи та методології [7,8] екстремального керування проектами та екстремального програмування, які можна з повною упевненістю віднести до цього стилю.

Умови формування стилів

Крім внутрішньої логіки організації проекту стиль має ще й оптимальними умовами свого існування. Слідуючи логіці Мінцберга [1], найбільш важливим параметром оточення проекту є невизначеність. При цьому велике значення має невизначеність у двох аспектах: 1) процес реалізації ІТ-проекту (наприклад, передбачуваність процесу впровадження ERP-системи) і 2) бізнес-відносини, пов'язані із зобов'язаннями учасників (наприклад, контрактні відносини із зовнішнім підрядником). В якості зовнішнього середовища проекту виступає внутрішня обстановка бізнесу, як замовника так і самого підрядника.

Для опису характеристики зовнішніх умов проекту можна використовувати той же квадрат невизначеності [2], що був нами використаний для опису умов бізнесу (Рис.1). Але зміст характеристик невизначеності за його осях буде вже іншим (Рис.2).

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

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

Висока невизначеність. Велика сильно інтегрована модульна ERP-система. У такій системі безліч зв'язків виходять за рамки системного ядра, і утворює складну мережу, утримати яку в полі зору здатна тільки вузька група професіоналів. Чим більше така система, тим швидше зростає її складність і невизначеність її поведінки. У зону високої невизначеності можна потрапити навіть з коробковими продуктами. До цього можуть підштовхнути 1) низька кваліфікація консультантів і розробників або 2) сильна інтеграція великої кількості стандартних коробкових продуктів (досить 5 систем).

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

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

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



Рис.2. Квадрат невизначеності – опис умов проекту.

У кожного стилю своя «середовище проживання». Кожен стиль має свою внутрішню логіку організації, яка породжує свої «вроджені» проблеми (Рис.3.) І має свій «вроджений» профіль витрат [2]. Проект подібний організму – якщо організм живий і діє, то у нього завжди щось болить. Абсолютно без проблем обходиться тільки мертвий чи ідеальний проекти.

Рис.3. «Вроджені» проблеми стилів проектів

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

Динаміка стилів

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

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


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

Висновки

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



  1. Різноманітність стилів проектів набагато більше, ніж розглянуто в даній статті.
  2. Стилі проекту характерні не тільки для області ІТ, а носять більш універсальний характер.

Виділення стилю проекту і контроль його динаміки має важливе практичне значення як для оперативного управління окремими проектами, так і стратегічного управління всією проектною діяльністю.

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

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

Використання стилю дозволяє готувати збалансовані умови проекту вже в ході переговорів на передконтрактної фазі.

Практично використовуючи поняття стилю, компанія-інтегратор може провести більш тонке налаштування маркетингу і продажів у своєму проектному бізнесі.


Література

1. Г. Мінцберг, «Структура в кулаці. Створення ефективної організації », Пітер, СПб, 2001.
2. В.І. Ананьїн, «Стійкість управління ІТ проектами в умовах невизначеності», журнал «Управління проектами», 2005, № 1,2, Видавничий Дім Грєбєннікова, Москва
3. «A guide to the Project Management Body of Knowledge», 2000 Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
4. IPMA Competence Baseline (ICB), Version 2.0b, Bremen, 1999/2001, International Project Management Association
5. «Federal Acquisition Regulation», General Services Administration Department of Defense National Aeronautics and Space Administration, 2001
6. В.І. Ананьїн, «Формування архітектури корпоративної інформаційної системи шляхом природного відбору», Intelligent Enterprise № 17 (149) 26 вересня 2006
7. Р. Томсетт, «Радикальне управління ІТ проектами», Лорі, Москва, 2005
8. Дуг Декарло, «Екстремальне управління проектами», ред. А. Баженов, А. Ареф 'єв, pmOffice, Москва, 2005

Ананьїн Володимир Ігорович, Вільний консультант

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


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

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

Ваш отзыв

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

*

*