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

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

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

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

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

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

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

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

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

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

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

При цьому в усіх випадках питання про необхідність впровадження неодмінно САМІЙ СУЧАСНІЙ АИС під не ставився.

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

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

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

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

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

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

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

— Мені однаково… — сказала Алиса.

— Тоді всі одно, куди й йти — зауважив Кот".

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

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

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

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

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

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

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

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

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

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

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

— Яке нинішнє становище бізнесу заказчика?

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

— Чим обгрунтовані обрані приоритеты?

— Яке бажане стан і цілі бизнеса?

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

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

— Що варто робити наступним шагом?

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

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

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

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

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

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

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

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