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

12

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

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

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

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

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

Бен Брока
источник
4
Это программное обеспечение вендора, которое должно быть в высшей степени настраиваемым, или эти настройки выходят за рамки того, что в действительности подразумевал вендор для системы?
rjzii
@RobZ оба, но, как я пытался подчеркнуть, я обеспокоен настройками, которые напрямую влияют на данные, что система не должна делать. Он настроен так, что мы можем создавать свои собственные отчеты и формы, но сами данные не должны использоваться. Некоторых из них достаточно, чтобы поставщики сказали: «Ничего не могу поделать, изменение X придется изменить», что мы обычно должны исправить сами и не удалять настройку ...
Бен Брока
Существует ли четко определенный владелец продукта или другая структура управления вокруг системы? (Я пытаюсь найти канал связи, не говоря, что это ответ ...)
jcmeloni
если его финансовые данные и вы хотите сохранить их в безопасности, просто скажите «нет» из-за Сарбейнса-Оксли, вряд ли большинство из них когда-нибудь проверят, действительно ли вы правы. это закулисно, но достигает своей цели более прямо, чем пытаться объяснить другими способами
Ryathal
@jcmeloni, если я вас правильно понимаю, наш финансовый директор или бухгалтер делает запрос (обычно через финансового директора) в технический директор, который решает, кто и что будет делать. Я обычно даю CTO отчет о целесообразности / как это будет работать, и он передается финансовому директору, который решает, стоит ли задача X.
Бен Брока

Ответы:

4

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

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

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

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

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

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

Тим Косцельский
источник
10

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

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

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

Филипп
источник
4
И люди из отдела ИТ говорят: не устанавливайте багажник на крышу, чтобы отвезти этот стол домой. Позвольте нам спроектировать и построить новый автомобиль с нуля, который специально адаптирован к потребностям вашего рабочего стола. В конце концов, когда внутренний ИТ-проект когда-либо шел с ума со временем и бюджетом и не удовлетворял потребности бизнеса?
Мартин Беккет
1
Так что я думал об этом некоторое время, и аналогия все еще держится. Вы не идете к механику, чтобы спросить о багажниках на крышу. Вы берете инструмент, который у вас есть, и боретесь с ним, пока работа не будет выполнена. Если ваша профессиональная работа - перемещать столы круглый год, вы не пользуетесь автомобилем и багажником на крыше, вы покупаете грузовик.
Филипп
5

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

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

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

В частности:

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

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

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

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

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

jcmeloni
источник
2

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

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

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

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

AnthonyBlake
источник
1

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

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

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

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

bigtang
источник