문제명세서

Problem statement

문제성명은 해결해야 할 문제나 개선해야 할 조건에 대한 간결한 설명이다.공정 또는 제품의 현재(문제) 상태와 원하는(골격) 상태 사이의 차이를 식별한다.사실에 초점을 맞추어 문제성명은 5 W를 다루도록 설계되어야 한다.문제를 해결하는 첫 번째 조건은 문제를 이해하는 것인데, 이것은 문제성명을 통해 이루어질 수 있다.[1]

문제성명서는 대부분의 기업 및 단체에서 공정개선사업을 수행하기 위해 널리 사용된다.프로젝트 팀은 문제를 이해하고 해결책을 개발하기 위해 간단하고 명확하게 정의된 문제 문구를 사용할 것이다.또한 경영진이 적절한 프로젝트 승인 결정을 내릴 수 있도록 문제에 대한 구체적인 통찰력을 제공할 것이다.따라서, 문제 진술이 명확하고 명확해야 한다.[2]

목적

문제성명의 주요 목적은 문제를 파악하고 설명하는 것이다.여기에는 문제가 발생하는 기존 환경과 그것이 사용자, 재무 및 보조 활동에 미치는 영향에 대한 설명이 포함된다.[3]또한 문제성명은 예상되는 환경이 어떻게 생겼는지 설명하기 위해 사용된다.원하는 조건의 정의는 공정이나 제품에 대한 전체적인 비전을 제공한다.개선 프로젝트의 개시 목적과 달성하고자 하는 목표를 명확히 한다.[4]

문제성명의 또 다른 중요한 기능은 통신장치로 사용하는 것이다.문제성명은 프로젝트 관련자들로부터 매입을 얻는 데 도움이 된다.[3]프로젝트가 시작되기 전에 이해관계자는 문제를 확인하고 목표를 문제성명서에 정확하게 기술한다.일단 이 승인이 접수되면, 프로젝트 팀은 모든 사람들이 당면한 문제와 그들이 달성하고자 하는 바를 확실히 이해하기 위해 그것을 검토한다.이것은 또한 프로젝트 범위를 규정하는 데 도움이 되며, 이것은 프로젝트가 전체적인 목표에 집중되도록 한다.[5]

문제성명은 프로젝트 팀 내에서 초점을 설정하고 이들이 정상 궤도에 머무르는지 확인하기 위해 프로젝트 전체에 걸쳐 언급된다.프로젝트가 끝나면 구현된 솔루션이 실제로 문제를 해결하는지 확인하기 위해 다시 방문한다.잘 정의된 문제 진술은 또한 왜 문제가 발생했는지 이해하고 향후에 문제가 발생하지 않도록 조치를 취할 수 있도록 보장하기 위해 근본 원인 분석을 수행하는 데 도움이 될 수 있다.[2]

문제성명이 해결책에 도달하는 해법이나 방법을 정의하지 않는다는 점에 유의해야 한다.문제성명은 단순히 문제와 목표 상태의 차이를 인식한다."잘 진술된 문제가 절반으로 해결됐다"[4]고 할 수 있다.그러나 문제에는 종종 여러 가지 실행 가능한 해결책이 있다.문제 진술서를 작성하고 동의한 후에야 해결책을 논의하고 그에 따른 행동 방침을 결정해야 한다.[6]

문제 정의

문제 문을 만들려면 먼저 문제를 정의해야 한다.가능한 한 빨리 해결책을 찾기 시작하고 싶고, 해결되어야 할 진정한 문제의 정의를 무시하는 것은 인간의 본성이다.그러나 제대로 정의되지 않은 문제는 예상 결과를 완전히 충족시키지 못하는 솔루션을 구현하는 위험을 증가시킨다.문제가 완전히 이해되지 않으면 해결될 수 없다.[7]

그 문제를 정의하는 과정은 종종 집단적인 노력이다.이 문제는 이해관계자, 고객 및/또는 사용자(가능한 경우)와의 미팅에서 시작되며, 이 문제의 문제점을 파악한다.[8]사람들은 종종 그들의 문제를 효과적으로 전달하는데 어려움을 겪기 때문에, 특히 과정 밖의 누군가에게 근본적인 추리가 밝혀질 때까지 일련의 "왜" 질문을 하는 것이 도움이 된다."5 Why's"로 알려진 이 방법은 많은 경험된 좌절들이 실제 문제의 증상일 수 있기 때문에 핵심 문제를 파헤치는 데 도움이 된다.[6]이해관계자가 말한 내용을 패러프레이징하는 것뿐만 아니라 이러한 추가적인 질문들을 하는 것은 그 문제에 대한 공감과 이해의 정도를 보여준다.[5]

이러한 초기 인터뷰로부터 수집된 정보는 문제 분석의 한 부분일 뿐이다.여러 번 문제는 이해관계자, 고객 및 사용자가 알지 못하는 여러 영역 또는 기능으로 확장된다.그들은 또한 표면에서 일어나는 일에 익숙할 수도 있지만 반드시 근본적인 원인은 아니다.따라서, 프로젝트 팀 구성원들과 그 문제에 관한 주제 전문가들로부터 지식, 정보, 통찰력을 수집하는 것은 필수적이다.[8]작업 지침서, 사용자 매뉴얼, 제품 사양서, 워크플로우 차트, 이전 프로젝트 계획서 등 추가 연구 자료도 참조할 필요가 있을 수 있다.공정 개선 프로젝트의 대부분의 다른 단계들처럼, 전체 상황을 파악하기 위해 몇 차례의 논의가 필요할 수 있기 때문에 문제를 정의하는 것은 종종 반복적이다.[2]

문제가 파악되고 프로젝트 시작을 추진하는 상황이 명확해지면 문제성명서를 써야 할 때다.

문제 진술서 작성

문제성명은 프로젝트 지원과 이해관계자의 승인을 얻기 위해 사용될 것이다.그만큼 행동 지향적이어야 한다.[3]더 중요한 것은 성공적인 결과를 전달하기 위해서는 문제성명을 명확하고 정확하게 작성해야 한다는 점이다.잘못 만들거나 잘못된 문제 진술은 시간, 돈, 자원을 낭비할 뿐만 아니라 잘못된 해결책으로 이어질 것이다.[1]

프로젝트 실패의 위험을 줄이기 위해 모든 문제 진술에 내장할 수 있는 몇 가지 기본 요소가 있다.첫째, 문제 서술문은 최종 사용자에게 초점을 맞추어야 한다.일반적인 실수는 현재의 격차보다는 문제가 어떻게 해결될지에 초점을 맞추고 있다.둘째, 문제 진술이 너무 광범위해서는 안 된다."5가지 이유" 접근법을 사용하면 문제를 이해하고 적절한 솔루션을 개발하는 데 필요한 세부 정보를 제공함으로써 과도한 단순성을 피할 수 있다는 장점이 있다.마지막으로, 문제 진술이 너무 좁으면 안 된다.솔루션 바이아는 솔루션을 브레인스토밍하는 동안 발생하는 창의성을 억제하며, 사용자에게 최적의 경험이 되지 않을 수 있다.[8]

문제성명서를 작성할 때 특정 형식을 설계하고 따르는 것이 유용하다.이를 위한 몇 가지 옵션이 있지만, 다음은 문제 정의에 초점을 맞추기 위해 비즈니스 분석에서 자주 사용되는 간단하고 간단한 템플릿이다.

  1. 이상: 이 절은 공정 또는 제품의 원하는 상태 또는 "있을" 상태를 설명하는 데 사용된다.이해관계자와 고객의 목표를 파악하고 범위를 정의하는 데 도움을 준다.일반적으로 이 섹션은 솔루션이 구현되면 예상되는 환경이 어떻게 보일지 설명해야 한다.
  2. 현실: 이 절은 공정 또는 제품의 현재 또는 "있는 그대로" 상태를 설명하는 데 사용된다.이해관계자와 고객이 표현하는 고충을 설명한다.또한 문제 분석 시 제공되는 프로젝트 팀 및 주제 전문가의 통찰력과 전문성도 포함해야 한다.
  3. 결과:이 절은 문제가 해결되거나 개선되지 않을 경우 사업에 미치는 영향을 설명하는 데 사용된다.여기에는 금전적 손실, 시간, 생산성, 경쟁우위 등과 관련된 비용이 포함된다.이러한 효과의 규모 또한 프로젝트의 우선순위를 결정하는 데 도움이 될 것이다.
  4. 제안: 이 섹션은 잠재적 해결책을 설명하는 데 사용된다.이상, 현실, 결과 섹션이 완성되고, 이해되고, 승인되면, 프로젝트 팀은 문제 해결을 위한 옵션 제공을 시작할 수 있다.구체적인 행동방식이 결정되기 전에 추가적인 논의와 연구가 필요하겠지만 이해관계자와 고객의 제안도 포함될 수 있다.[7]

이 형식을 따르면 모든 당사자가 문제를 이해하고 성공적인 해결책으로 이어질 요구사항을 도출하기 위해 사용할 수 있는 실행 가능한 문서가 된다.

예

문제의 복잡성에 따라 문제 진술의 길이가 달라질 수 있다.다음은 Single Sign On 기능 생성을 위한 간단한 문제 설명의 예입니다.

이상 :

이상적으로는 당사의 사용자가 노트북에 로그인한 후 사용해야 하는 모든 애플리케이션에 자동으로 액세스할 수 있을 것이다.

현실:

실제로 우리는 우리의 일을 성취하기 위해 매일 적어도 세 개의 애플리케이션을 사용한다.각 애플리케이션은 사용자 이름과 암호 길이에 대한 요구 사항이 다른 암호로 보호된다.비밀번호는 또한 다른 시간에 만료된다.

결과:

  • 사용자는 여러 애플리케이션에 로그인하는 데 하루에 약 2분을 소비한다(사용자가 500명일 경우 500명 * 매일 2분 = 생산성 손실 1000분, 1000분 = 16.67시간 * 매일 75달러 = 1250달러).
  • 헬프데스크는 잊어버린 암호를 재설정하고 계정 잠금을 해제하기 위해 매년 약 6000건의 통화를 해결한다.
  • 사용자가 책상에 있는 스티커 메모에 사용자 이름 및 비밀번호를 계속 작성하기 때문에 보안 위험.

프로포즈

S/W Dev, Network Administration 및 비즈니스 이해 관계자가 협력하여 Single Sign On 기능에 대한 잠재적 솔루션을 평가하십시오.

참조

  1. ^ a b Kush, Max (June 2015). "The Statement Problem". Quality Progress. 48 (6).
  2. ^ a b c Annamalai, Nagappan; Kamaruddin, Shahrul; Azid, Ishak Abdul; Yeoh, TS (September 2013). "Importance of Problem Statement in Solving Industry Problems". Applied Mechanics and Materials. Zurich. 421: 857–863. doi:10.4028/www.scientific.net/AMM.421.857. S2CID 60791623.
  3. ^ a b c Gygi, Craig; DeCarlo, Neil; Williams, Bruce (2015). Six sigma for dummies. Hoboken, NJ: John Wiley & Sons. pp. 76–78.
  4. ^ a b Lindstrom, Chris (2011-04-24). "How To Write A Problem Statement". www.ceptara.com. Retrieved 2018-04-10.
  5. ^ a b Perry, Randy; Bacon, David (2010). Commercializing Great Products with Design for Six Sigma. Prentice Hall. p. 18.
  6. ^ a b Shaffer, Deb (2017-07-12). "How to Write a Problem Statement". ProProject Manager. Retrieved 2018-04-10.
  7. ^ a b Shaffer, David (2015-12-21). "Cooking Up Business Analysis Success". BA Times. Retrieved 2018-04-10.
  8. ^ a b c Widen, Steven (2018-04-02). "Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes". Forbes. Retrieved 2018-04-10.