У пошуках згоди

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

Великі розподілені проекти автоматизації діяльності торгових представників (Sales Force Automation, SFA) приречені мати всі необхідні атрибути проектного менеджменту: статут проекту, схему комунікацій, обов'язкова наявність всіх базових ролей з їх чітким і однозначним розподілом (спонсор, керівник, аналітик, економіст та ін. ). Відзначимо, що деякі з цих ролей в маленьких проектах зайві.

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

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

Секретар проекту з боку виконавця організовує і погодить зустрічі, веде протоколи, складає розклад відряджень керівників і т.д.

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

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

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

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

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

Впровадження як ітераційний процес

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

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

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

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

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

З першим пунктом все ясно. Клієнт уважно придивляється до постачальника, намагаючись знизити ризики неправильного його вибору. Другий пункт означає, що пілотний проект - перша ітерація циклічного процесу «уточнення вимог - розробка і тестування - впровадження - уточнення вимог». Після впровадження з'являється певний досвід експлуатації. Народжуються нові і уточнюються старі вимоги до SFA. Технічне завдання, таким чином, змінюється. В мережевому проекті, де будь-який, навіть дрібне відхилення від «ідеалу», буде багаторазово тиражувати, краще провести кілька ітерацій пілотних проектів, поступово уточнюючи і допрацьовує вимоги. Третій пункт пов'язаний з тим, що зазвичай вже на першому етапі проекту клієнт дізнається про себе багато нового. Наприклад, може з'ясуватися, що виробникові дуже важко домовитися з дистриб'юторами. Іноді його організаційна структура не готова до проведення такого масштабного проекту в задані терміни. Це призводить до зміни меж проекту і перегляду всієї його траєкторії прямо в процесі виконання.

«Продаж» проекту дистриб'юторам

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

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

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

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

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

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

устаткування

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

Жоден виробник не в змозі протестувати ПО у всіх можливих варіантах використання. Наприклад, одна з наших програм для КПК містить більше 150 настроювальних параметрів для обліку специфіки клієнта. Кількість всіх можливих конфігурацій для тестування одно 10 в 45-го ступеня - неймовірно велика кількість варіантів. Навіть якби все населення Землі цілодобово займалося тестуванням нашого ПО, знадобилося б час, в сотні мільярдів разів перевищує вік нашої Галактики! Тому ПО завжди ретельно тестується лише для невеликої кількості очевидних ситуацій, а їх підбір визначається досвідом виробника. У конкретному випадку завжди може скластися які раніше не перевірена комбінація параметрів, в якій ПО дасть збій.

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

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

Особливості формування бюджету

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

Юридичні взаємини

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

Мета - стратегічне партнерство

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

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

Ризики стратегічного партнерства

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

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

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

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

Сергій Максименко - генеральний директор OOO «Системні технології»; [email protected]

Жорсткі і м'які мережі

Жорсткої називають територіально розподілену дистриб'юторську компанію з централізованим управлінням системою регіональних підрозділів, єдиними стандартами ведення бізнесу і загальною системою управлінського та бухгалтерського обліку. М'якої - мережа, організовану виробником з локальних Дистрибьюторс компаній. Фактично існує безліч локальних дистриб'юторів, які надають виробнику послугу на певній території, а виробник тільки структурує дану послугу. Структура існує тільки з точки зору виробника, так як з точки зору локального дистриб'ютора він просто надає послугу по заданих ззовні стандартів в силу своїх можливостей. Детально про проблеми автоматизації тих і інших розповідається в статті «Масштаб має значення» (Див. «Директор ІК», № 6/2008).

Ключові уроки

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

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

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

Критичним фактором успіху проекту є обов'язкова інтеграція SFA з обліковими системами локальних дистриб'юторів.

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

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

Ідеальні відносини між постачальником і клієнтом в проекті SFA для великої мережі - стратегічне партнерство.