Корпоративна автоматизована інформаційна система як ресурс бізнесу (як поставити ІТ на службу бізнесу?)

Сергій Цодіков, генеральний директор групи компаній «Форус»

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

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

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

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

Скажіть, чи можна назвати розумною причиною побудови АІС ПРОЦЕС автоматизації бізнесу? Навряд чи, хіба що з безкорисливої любові керівника до ПРОЦЕСУ автоматизації або як данини до моди. Раціональною причиною застосування АІС в бізнесі є НЕОБХІДНІСТЬ РІШЕННЯ бізнес задач. Чи розуміє це до кінця замовник, а часто і виконавець проекту автоматизації? Судіть самі. Ось типові витримки з опитувань керівників з постановки задачі і визначенню цілей проекту побудови АІС, які систематично проводяться відділом маркетингу нашої компанії:

1) Директор регіональної компанії: «Мені потрібно, щоб мені необхідна інформація була завжди під рукою. Бажано, щоб кількість її розрізів було максимальним ». Спроба уточнення цілей приводила до відповідей: «Я в інформаційних технологіях нічого не розумію, Ви - «інформаційників», Вам і карти в руки. А мені треба, щоб у мене було все добре з інформацією: вона повинна бути своєчасна, точна і повна! Зробіть це для мене ».

2) Директор великої столичної оптової компанії: «У мене постійна проблема з прийомом замовлень - не бачу я забезпеченість замовлення товарною продукцією. Добре б знати - де і який товар знаходиться: на складі, зарезервовано під замовлення і на який термін, в дорозі, в комплектації. От якби я знав це, у мене не було б проблем. Це і є суть нашого замовлення на розробку АІС ».

3) Директор виробничої компанії: «Ми заклали гроші в бюджет на інформаційні технології. Ідіть до бухгалтеру/директору з інформаційних технологій - він/вони Вам все розповість ».

При цьому у всіх випадках питання про необхідність впровадження неодмінно НАЙБІЛЬШОЇ СУЧАСНОЇ АІС під сумнів не ставилося.

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

В третьому випадку цілі бізнесу підміняються частковими і головне, що забезпечують цілями функціональних підрозділів. Питання в тому, чи знають вони цілі бізнесу? Гроші будуть витрачені з високим рівнем контролю, ось тільки під який розумний бізнес-результат?

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

Отже, ключова проблема успішного проекту АІС полягає в тому, як замовник розуміє цей проект: як витратний або як інвестиційний. Багаторічний досвід роботи показує, що тільки 4 - 5%% керівників ставлять перед проектом впровадження АІС по справжньому інвестиційні завдання. Іншими словами, необхідною умовою успішності проекту АІС має стати його націленість на кінцеві, а не проміжні цілі та результати бізнесу.

І ось тут починається найцікавіше. При спробі прояснити цілі бізнесу, розмову з керівником компанії до болю нагадує алегоричний діалог Аліси і Чеширського кота з книги Льіса Керрола «Аліса в країні чудес»:

« - Скажіть будь ласка, куди мені звідси йти? - Спитала Аліса.

-- А куди ти хочеш потрапити? - Відповів Кіт.

-- Мені все одно ... - сказала Аліса.

-- Тоді все одно, куди і йти - зауважив Кот ».

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

1. Доступ розробників АІС до вищого керівництва компанії замовника, що потенційно є «носієм» знання про цілі і реальні проблеми свого бізнесу.

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

3. Компетентність розробника АІС - його здатність переводити бізнес - завдання в мети проекту АІС.

Слід відзначити, що існуюча теорія проектування АІС, хоча і підкреслює важливість фази виявлення вимог до АІС, виходить з припущення, що цілі, бажаний стан об'єкта автоматизації, а значить - вимоги до АІС, відомі замовнику до початку проекту. Розробнику необхідно сформулювати, зафіксувати і схвалити їх у замовника в ході системно-аналітичного обстеження підприємства. Це положення закріплюється як базовий у всіх навчальні програми з підготовки АІС фахівців. Воно виступає як певний вододіл між бізнес - та ІТ консалтингом. І тому, що його «так вчили і так положено », розробник АІС поводиться у відповідність до принципу« чого бажаєте », виконуючи АІС проект так, як ніби учасники виробили узгоджене, точне і певне розуміння його цілей. І розробник АІС проводить опитування, виявляє і аналізує вимоги замовника, які з високою ймовірністю не відповідають його бізнес цілям. Чи не тут лежать причини скептичних зауважень частини топ менеджменту про марність АІС, про нечесних і корисливих інформаційників, тільки й думають про те, як би побільше заробити на погано розбираються в особливостях інформаційних технологій керівників?

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

Проілюструємо підхід і оцінимо його результативність на прикладі впровадження АІС для одного з наших замовників.

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

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

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

Таким чином, процесний консультант ще до початку проекту АІС, разом із замовником повинен чітко і ясно сформулювати відповіді на такі «прості» питання:

-- Яке існуючий стан бізнесу замовника?

-- Які напрямки рухається бізнесу та їх пріоритетність?

-- Чим обгрунтовуються вибрані пріоритети?

-- Яке бажаний стан і цілі бізнесу?

-- Які завдання слід вирішити, щоб домогтися бажаного стану?

-- Які порядок вирішення завдань та критерії, що сигналізують, що рішення досягнуто?

-- Що слід робити наступним кроком?

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

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

Список літератури

Друкер П. Завдання менеджменту в ХХI столітті. - М.: Видавничий дім «Вільямс», 2000.

Гейтс Б. Бізнес зі швидкістю думки. - М.: Из-во ЕКСМО-Прес, 2001.

Керролл Л. Аліса в країні чудес. - М.: Наука, 1990.

Уілсон С., Мейплс Б., Лендгрейв Т. Принципи проектування й розробки програмного забезпечення. - М.: Видавничо-торговий дім «Русская Редакция», 2000.

Kendall K, Kendall J. Systems Analysis and Design. - New Jersey: Prentice - Hall, Inc., 1988.