공급 업체 소프트웨어 변경의 위험을 어떻게 알 수 있습니까?

우리는 내가 일하는 데 큰 문제가 있으며 그 이름은 "사용자 정의"입니다. IT 및 회계 부서에서 이전 에 사용자 정의하기를 좋아했던 오래된 (10 년 이상) 공급 업체 소프트웨어 시스템이 있습니다. 이 소프트웨어는 어딘가에서 버그가 발생하기 시작했습니다. 그런 다음 대량의 사용자 정의 후에 고용되었습니다.

시스템에서 발견 한 거의 모든 문제는 사용자 정의의 직접적인 결과입니다. 우리가 변화시키는 모든 것은 업무상 중요한 재무 소프트웨어를 파괴 할 위험이 있습니다. 그러나 회계 부서는 변화를 제안하고 (우리가 항상 그렇다고 말했기 때문에) 변화가 얼마나 영향 을 미치는지에 대해서는 거의 존중하지 않는 것 같습니다 .

일부 변경 사항은 문제를 일으키지 않습니다. 양식은 공급 업체 소프트웨어에서 사용자 정의 할 수 있으며 양식 필드를 이동하고 제거 할 수 있습니다. 그러나 모든 무해한 사용자 정의의 경우 공급 업체 응용 프로그램의 데이터베이스에서 데이터를 조작하는 저장 프로 시저 및 트리거와 같은 변경 사항도 제안합니다.

최근 정보가 완전히 호환되지 않기 때문에 한 공급 업체 프로그램에서 다른 공급 업체 프로그램으로 고객을 가져 오려는 시도를 중단했습니다. 해결 방법에 대한 내 문제는 시스템이 사용자 측에서 작동하지 않는 것을 발견했기 때문입니다. 과제는 생각보다 복잡해서 포기했습니다. 사용자측 작업이 얼마나 쉬운 지에 관계없이 원하는 작업을 수행해서는 안됩니다.

이 시스템의 작동 방식을 변경하면 특히 데이터 유효성에 문제가있을 때 위험이 있다는 것을 어떻게 알 수 있습니까? 저는 새 (6 개월) 고용 상태이며 현 상태가되었지만 재무 데이터 및 지원 계약의 유효성을 위험에 빠뜨립니다. 공급 업체의 지원에 "X가 사용자 정의되었습니다"라는 말이 들리면 많은 이유가 없습니다. 우리를 지원하거나 우리의 잘못이라고 우리에게 말하십시오.

시스템 커스터마이징의 위험 / 보상은 회사가 다른 지역의 비즈니스와 다른 것을 제공 할 수있는 경쟁 우위를 제공하는 것입니다.

내가 함께 일한 대기업은 커스터마이즈에서 경쟁 우위를 얻었으며, 그 사고 방식에서 업무를보다 효율적으로 수행하고, 더 많은 기능을 제공하거나, 더 많은 돈을 벌 수 있습니다.

이 상황에서 내가 의사 소통한다는 것은 그것이 절충안이라는 것입니다. 이러한 변경 사항을 시스템에 적용하기 위해 조직은 자체적으로 쉽게 수행 할 수없는 자체 내부 지식 기반 / 시스템 전문가를 개발하고 있습니다. 이러한 내부 지식 기반은 이러한 변경 사항을 추적하고 관리 할 수 ​​있도록 더 잘 유지 관리되고 구성되어야합니다. 또한 벤더 지원 계약 및 회사가이 프로세스에 사용하는 IT 자산의 기타 측면을 무효화 할 수 있음을 의미합니다.

제가 이야기하는 가장 큰 위험은 회사가이 데이터 관리 철학을 채택 할 때 공급 업체 소프트웨어로의 버전 업그레이드입니다. 이는 문제가 발생할 가능성이 가장 큰 위험 중 하나입니다. 회사는 진행중인 트레이드 오프를 이해해야하며 모든 사람이이를 지원하는 프로세스에 참여해야합니다.

문화의 경우 비유 나 철학을 도입 할 수 있지만 이러한 시스템을 변경하는 내부 비즈니스 전문가에게 더욱 의존하는 환경을 만들고 있다는 사실을 비즈니스 담당자가 알아야합니다.

자동차 비유의 경우 자동차에 어떤 변화가 있는지 알아야하는 정비공이 아니라 자동차 정비사가 특정 정비공, 더 많은 돈 또는 일정 기간 동안 해당 서비스를 잃을 수 있음을 이해해야하는 소유자입니다. 이 대화의 열쇠는 주인을 교육하는 것입니다.

사무실 거주자와의 커뮤니케이션? 나는 유추와 함께 갈 것입니다.

이 모든 변화가 전형적인 4 도어 가정용 세단을 이국적인 외국 자동차로 바꾸고 있다고 말하십시오. 튜닝에서 파쇄 된 빛, 변속기 점검에 이르기까지 정비공 상점에 가져갈 때마다 비용이 더 많이 듭니다. "우리는 부품이 없으며, 특별한 지식을 가진 딜러 만이 그것을 만질 수 있습니다. 우리는 시도했지만 매뉴얼은 독일어입니다."

당신은 그것을 계속 운영하는 정비공입니다. 데이터베이스는 엔진입니다. 전체 시스템은 자동차입니다. 회계사는 차를 운전합니다. 회계사가 놓친 귀여운 작은 토끼는 새 고객의성에 움라우트 문자입니다. 그들이 차를 감싸고있는 전등 기둥은 차 안에 디스코 볼을 추가하고 싶을 때 소개 된 중요한 버그입니다.

다른 사람들은 주요한 질문에 대답하기 위해 유추와 다른 언어를 사용하는 좋은 예를 제시했습니다. "이 시스템의 작동 방식을 바꾸는 것이 특히 데이터 유효성에 문제가있을 때 어떻게 위험을 감수 할 수 있습니까?"

그러나 과제 배정이 당신에게 어떻게 전달되는지에 대한 당신의 명확한 의견을 바탕으로, 나는 어떤 비유가 상황에서 당신을 도울 것이라고 확신하지 못합니다-사람들이 그들이 요구하는 것을 오해하는 것은 아니지만 오히려 그들은 상관하지 않습니다. 나는 거기에 있었다 – 우리 모두는 아마 거기에 있었다 – 그리고 이러한 상황에서 나는 경고 하기보다는 가르치기 위한 용어로 문제를 해결하기보다는 문제에 대해 완벽하게 분명하게 하기 위해 더 많은 노력을 기울이는 경향이있다 .

당신은 무엇에 초점을 수 있습니다 혼자 힘으로 대신 위험에 데이터 무결성 및 공급 업체 지원 계약을 넣어 사용자 지정을 요청하는 모든 사람의 마음을 변화하는 것이 아니라, 할, 당신의 CTO (차례로의 CFO)와 존재에 직접 말하는 당면한 문제에 대해 매우 분명합니다.

구체적으로 특별히:

• CTO 또는 CFO (또는이를 보유한 사람)에게 공급 업체와의 서비스 계약을 확인하도록 요청하십시오. 계약에 위배 될 수있는 작업을 수행해야하므로 작업 타당성 보고서에서이를 지적 할 수 있습니다. 그들은 당신에게 그것을 제공하지 않을 수도 있지만, 그 말을하면 그 위치에있는 사람들이 종종 당신이 심각하다는 것을 더 잘 이해하게되며 상황은 잠재적으로 심각합니다.

• 당신이 경우에 할 계약의 사본을 얻을 명백한 위반이있을 때, 당신은 당신의 작업 타당성 보고서를 작성 후 때, 그것에서 직접 인용.

• 당신이 경우 되지 계약서의 사본을 얻을, 당신의 예약은 매우 변화가에 관해서는 나쁜 위치에 공급 업체와의 관계를 회사를 넣을 수있는 방법으로 취소합니다.

• 공급 업체 계약으로 인해 문제가되지 않지만 변경으로 인한 영향으로 인해 "단순하게"문제가되는 경우 그 의미를 설명하십시오. 말한대로 지저분 해지면 한두 가지만있을 것입니다. "카드 하우스처럼 쓰러 질 것입니다."

한마디로, 문제를 명확하고 간결하게 지적하기 위해 할 수있는 일과 그 효과를 한두 단계 내릴 수 있습니다. 의사 결정자에게 타당성 보고서를 이미 제출할 기회가 있다는 것은 좋은 일입니다. "구조가 나 관리 지원 (또는 정신)이 없다"는 말입니다. "이것은 나쁜 일이라는 것을 이해하고이를 권장하지 않으며 이로 인한 영향에 대해 책임을지지 않겠다는 말에 서명해야합니다. 나쁜 결정 "(공급 업체이고 고객 인 경우와 같이), 여전히 회사와 그 자산에 가장 관심이있는 것을 고려하고 있다는 것을 보여주는 종이에 많은 것을 넣을 수 있습니다.

이들이 저장 프로 시저 및 트리거를 구현하라고 지시하는 경우 주요 비즈니스 프로세스 문제가 있습니다.

가장 큰 과제는 여기에 사용자가 생각을 바꾸도록하는 것입니다. 문제 또는 요구 사항을 제공해야합니다. 예를 들어, 우리는 데이터에서 이동이 필요 여기 에 여기에 .

그것은 최소한의 위험 / 가장 이득이 솔루션을 구현하고 당신을해야하고, 그 것이다 당신 의 미래 개발 문제를 방지하는 데 도움이되는 방식으로이 작업을 수행 할 수있는 사람.

사용자 사인 오프 또는 요구 사항의 형태로 제어 한 다음 제공된 개발의 사인 오프도 도움이됩니다. 사용자가 원하는 것에 대해 책임 / 책임을 가져야하는 경우 조금 더 생각할 수 있습니다.

당신은 당신의 선택이 비즈니스 요구의 위험한 구현 사이에 있거나 전혀 아님을 암시하는 것 같습니다. 그 검은 색과 흰색은 거의 없습니다. 회계사가 직접 저장 프로 시저를 요구한다고 믿는 데 어려움을 겪고 있지만 필요한 경우 요청하는 것이 아니라 의미 를 부여해야 합니다. 비즈니스 요구 사항이 무엇인지 파악한 다음 가장 위험이 적은 방법으로이를 구현하십시오.

공급 업체가 후크를 제공하지 않으면 사용자가 원하는 요구 사항을 안전하게 구현해야하는 경우 사용자가 아닌 공급 업체에 문제가있는 것입니다.

기본적으로 소프트웨어를 개발 중이므로 개발 방법이 필요합니다. 변경 사항은 어떻게 문서화됩니까? 테스트 했습니까? 품질 관리에 배포 하시겠습니까? 프로덕션에 배포 하시겠습니까? 등등. 나는 당신이 방법론을 생각해 내고 그것과 관련된 비용을 이해하기 시작할 것이라고 생각합니다. 아마도 비용이 충분히 정당화되고 절차를 구현하면 자동차가 전등 기둥을 감싸지 않을 것입니다.