Как я могу сообщить о рисках изменения программного обеспечения поставщика?

У нас есть серьезная проблема, когда я работаю, и ее зовут «настройка». У нас есть старая (более 10 лет) система программного обеспечения, которую наши ИТ-отделы и отделы бухгалтерии ранее любили настраивать. Где-то вдоль линии это программное обеспечение стало очень глючным. Затем я был нанят после основной части настройки.

Почти каждая проблема, с которой я столкнулся в системе, является прямым результатом настройки; все, что мы меняем, рискует сломать критически важное финансовое программное обеспечение. Тем не менее, бухгалтерия продолжает предлагать изменения (потому что мы всегда говорили да!), И, кажется, мало уважения к тому, насколько эффективными могут быть изменения.

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

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

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

Риск / выгода от настройки систем заключается в предоставлении конкурентного преимущества, которое позволяет вашей компании предлагать что-то не так, как другие компании в вашем пространстве.

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

Тот факт, что я общаюсь в таких ситуациях, заключается в том, что это компромисс. Внося эти изменения в систему, организация разрабатывает собственную внутреннюю базу знаний / экспертизу своих систем, что они не смогут легко сделать без них. Эту внутреннюю базу знаний необходимо лучше поддерживать и организовывать, чтобы эти изменения можно было отслеживать и контролировать. Это также означает, что это может сделать недействительными контракты на поддержку поставщика и другие аспекты, которые ИТ-активы используют для этого процесса.

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

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

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

Общение с офисными жителями? Я бы пошел с аналогиями.

Скажите им, что все эти изменения превращают ваш типичный 4-дверный отечественный седан в экзотическую иномарку. Каждый раз, когда вы приносите его в механический цех, от настройки, до сломленного света, до капитального ремонта трансмиссии, это будет дороже. «У нас нет запчастей, только дилер с особыми знаниями может прикоснуться к этому, мы пробовали, но руководство на немецком языке».

Вы - механик, отвечающий за его работу. База данных является двигателем. Вся система это машина. Бухгалтеры водят машину вокруг. Милый маленький зайчик, которого бухгалтеры не заметили, - это умлаутский персонаж в фамилии нового клиента. Фонарный столб, вокруг которого они обернули свою машину, является критической ошибкой, которая появилась, когда они захотели добавить диско-шар в машину.

Другие предоставили несколько хороших примеров использования аналогий и другого языка для ответа на ваш основной вопрос: «Как я могу сообщить, что изменение работы этой системы сопряжено с риском, особенно когда на карту поставлена ​​достоверность данных?»

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

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

В частности:

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

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

• Если вы не получите копию соглашения, сделайте очень четкие оговорки относительно того, как изменение может поставить компанию в плохое положение в отношении отношений с поставщиком.

• Если ваша проблема не является проблематичной из-за соглашения с поставщиком, но «просто» проблематична из-за каскадных эффектов изменений, обрисуйте в общих чертах, что это означает: если это так грязно, как вы говорите, то, вероятно, у вас есть только один или два пунктами, прежде чем вы сможете использовать линию «и он будет падать, как карточный домик».

Короче говоря, делайте все возможное, чтобы очень четко и кратко указать на проблему и ее последствия, хотя бы на шаг или два ниже. Хорошо, что у вас уже есть возможность представить технико-экономическое обоснование лицам, принимающим решения; у вас нет структуры или управленческой поддержки (или этики), чтобы сказать: «Мне нужно, чтобы вы подписали это, сказав, что вы понимаете, что это плохо, и я не рекомендую это и не буду нести ответственность за последствия этого». плохое решение »(как вы могли бы, если бы вы были продавцом, а они были клиентом), но вы все равно можете положить на бумагу много вещей, которые показывают, что вы рассматриваете то, что отвечает интересам компании и ее активов.

Если они говорят вам о реализации хранимых процедур и триггеров - у вас есть серьезная проблема бизнес-процесса.

Ваша самая большая задача состоит в том, чтобы заставить пользователей изменить свое мышление. Они должны предоставить вам проблему или требование. Например, нам нужно перемещение данных из здесь , чтобы здесь .

Именно вы внедряете решение с наименьшим риском / наибольшим выигрышем, и именно вы можете сделать это таким образом, чтобы предотвратить проблемы будущего развития.

Также поможет некоторый контроль в форме пользовательского подтверждения или требований, а затем выхода из поставленной разработки. Если пользователь должен взять на себя некоторую ответственность / ответственность за то, что он просит, он может подумать об этом немного больше.

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

Если ваш поставщик не предоставляет возможности, необходимые для безопасного выполнения требований, которые хотят ваши пользователи, то эта проблема связана с поставщиком, а не с вашими пользователями.

Вы в основном разрабатываете программное обеспечение, и поэтому вам нужна методология разработки. Как документируются изменения? Испытано? Развернуто в QA? Развернуто на производство? и т.д. Я думаю, что если вы начнете придумывать методологию и связанные с этим затраты, они начнут понимать. Возможно, затраты вполне оправданы, и вам просто нужно внедрить процедуру, чтобы автомобиль никогда не оборачивался вокруг фонарного столба.