Як я можу повідомити про ризики зміни програмного забезпечення постачальників?

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

Майже кожна проблема, яку я знайшов із системою, є прямим результатом налаштування; все, що ми змінюємо, ризикує порушити важливе для бізнесу фінансове програмне забезпечення. І все ж бухгалтерія продовжує пропонувати зміни (адже ми завжди говорили так!), І, здається, мало поваги до того, якими можуть бути впливові зміни.

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

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

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

Ризик / винагорода при налаштуванні систем полягає у наданні конкурентної переваги, що дозволяє вашій компанії запропонувати щось інакше, ніж інші підприємства у вашому просторі.

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

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

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

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

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

Спілкування з мешканцями офісу? Я б пішов з аналогіями.

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

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

Інші навели кілька хороших прикладів використання аналогій та іншої мови, щоб відповісти на ваше основне запитання, яке було: "Як я можу повідомити, що зміна способів роботи цієї системи має ризики, особливо коли загрожує дійсність даних?"

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

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

Конкретно:

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

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

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

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

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

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

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

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

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

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

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

Ви в основному розробляєте програмне забезпечення, і як таке вам потрібна методологія розробки. Як задокументовані зміни? Тестували? Розгорнуто в QA? Виведений на виробництво? і т. д. Я думаю, якщо ви почнете розробляти методику та пов'язані з цим витрати, вони почнуть розуміти. Можливо, витрати цілком виправдані, і вам просто потрібно здійснити процедуру, щоб машина ніколи не загорталася навколо легкого стовпа.