이 문서의 번역:

I. 분석, 예측, 계획

첫 번째 Ignite | IoT 설계 아티팩트는 분석, 예측, 계획을 지원하기 위한 것이다. 초기 문제 설정 또는 경영 요약서는 종종 사업 모델에서 가져온 것이다 (Ignite | IoT 전략 실행 참조). 자세한 분석은 이상적으로 자산과 환경에 더 깊은 통찰력을 제공하는 현장 조사를 포함한다. IoT 솔루션 스케치는 한 페이지로 된 높은 수준의 솔루션 설계 제안 개요이다. IoT 프로젝트 차원은 프로젝트 자체 평가를 지원한다. 수량 구조는 사용자와 자산 등 주요 개체의 계획된 성장을 살핀다. 마지막으로, 이정표 계획은 프로젝트의 주요한 단계를 정의한다.

문제 설정/경영 요약서

위에서 말한 것처럼, 문제 설정 및 경영 요약서는 종종 사업 모델 단계에서 비롯된다. 이상적으로, 이는 사업 이해관계자가 쉽게 이해할 수 있는 언어를 사용하여 IoT 솔루션 문제 영역과 비전의 설명 한 페이지를 포함한다. 또한 핵심 솔루션 요소의 간단하고 직관적인 도표 개요를 제공한다. 아래 그림을 예로 참조하십시오.

                                 Executive summary
                                 

이해관계자 분석

프로젝트 맥락에서 이해관계자 분석을 위한 많은 모범 사례 체계가 있다 (예를 들어, 참조 추후결정). Ignite | IoT는 이해관계자 분석을 위한 IoT 고유의 체계를 기반으로 하며, 이는 원래 Heinz Derenbach 박사 (Bosch Software Innovations의 전 CEO)와 그의 팀에 의해 고안되었다. 이 팀에서 배운 한 가지 중요한 교훈은 대부분의 IoT 솔루션이 이해관계자와 연관된 네 개의 핵심 요소 - 자산과 해당 장치, 관련 기업의 서비스, 솔루션 사용자 및 파트너로 구성되어 있다는 점이다. 아래 그림은 IoT 솔루션의 네 가지 핵심 요소에 대한 개요를 제공한다.

Four key elements of an IoT solution

우리의 경험에 의하면, 이 네 가지 핵심 요소와 그들 간의 상호 의존성을 확인하고 정의하는 것은 IoT 솔루션의 주요 측면과 이해관계자 분석을 위한 아주 좋은 출발점이 될 것이다. 어떤 경우, 이들 요소 중 일부는 일반적으로 그들 사이의 상호 의존성에 대한 상세한 조사 없이 이미 사업 모델 분석에 포함되었을 수도 있다.

현장 조사

초기 IoT 솔루션 설계의 일환으로, 우리는 현장 조사 실시를 강력하게 권장한다. 이는 이상적으로 자산이 제조되는 공장 또는 사용되는 장소 등 관련 현장에 실제 방문하는 것으로 시작한다. 이를 보완하기 위해, 자산의 다른 측면과 자산이 일반적으로 배치되는 현장 (해당하는 경우)에 대해서 전문가들과 함께 면접을 진행할 수 있다.

현장 조사 문서는 다음과 같은 모든 자산 및 현장 고유의 측면을 포함해야 한다.

• 자산의 유형 – 예를 들어, 정적/동적 자산

• 자산의 분류 – 산업 분야, 예를 들어 제조업 또는 CPG

• 자산의 가동 – 지능이 없는 자산 (맥주 통 또는 팔레트 등) 또는 지능이 있는 자산 (자판기, PLC, 자동차 등)

• 사업 운영 및 자산 라이프사이클

• 솔루션 통합 – 기본 또는 개조

• 자산 인터페이스 – ModBus, CAN 버스, MDB, 직렬 버스, GPIO 등

• 자산의 인터넷 연결 – 셀룰러, 이더넷, 와이파이 네트워크

• 자산의 환경적 조건 – 작동 온도 또는 자산 위치 등 (움직이는 컨테이너 또는 차량 내부, 공장, 소매점, 옥외 등)

• 전원 공급 요건, 센서 설치 요건

조사 결과의 일부는 나중에 IoT 프로젝트 차원에 통합될 수 있다 (아래 참조).

솔루션 스케치

분석 결과에 기초하여, Ignite | IoT는 아래 그림에서 설명한 형식을 사용하여 높은 수준의 솔루션 스케치를 작성할 것을 권장한다. 이는 구조화된 형식으로 포착된 결과로, 종종 주요 이해관계자들이 참석하는 워크숍 중에 만들어질 수 있다.

                            IoT Solution Sketch                                                 

IoT 솔루션 스케치는 위의 “이해 관계자 분석” 부분에서 알아본 모든 네 가지 솔루션 요소를 포함하고 많은 중요 세부 사항을 추가한다. 예를 들어, 솔루션 스케치는 자산에서 백엔드까지 전송한 주요 사건 (또는 다른 주요 의사소통)을 식별하거나 정의하려고 시도한다. 또한, 핵심 UI, 사업 절차, 규칙 및 데이터 엔티티 (모두 리스트 형태로)를 포착한다. 게다가, 통합될 외부 파트너뿐만 아니라 데이터베이스 및 어플리케이션을 보여준다.

솔루션 스케치는 경영 요약서보다 더 자세하다. 그러나 핵심 개체에만 중점을 두며, 이러한 개체의 완전한 공식 목록을 제공하지는 않는다. 솔루션 스케치의 주요 목적은 솔루션의 범위를 좁히기 시작하고, 사업 및 기술 프로젝트 이해관계자들 간의 의사소통을 위한 공통의 기반을 만드는 것이다.

프로젝트 차원

Ignite | IoT는 IoT 솔루션의 모든 중요한 측면을 포착하는 데 도움이 되는 일련의 IoT 프로젝트 차원을 정의한다. 현재 다섯 가지 주요 차원과 총 약 40개의 하위 차원이 있다. 다섯 가지 주요 차원은 다음과 같다.

• 자산 및 장치: 수와 자산 가치, 자산의 복잡성, 필수 자산 처리 능력, 하드웨어 요건 및 라이프사이클 관리 등의 측면을 포함

• 통신 및 연결: 기술, 대역폭, 지역 및 원격 통신 대기 시간에 초점

• 백엔드 서비스: 백엔드 사업 솔루션의 복잡성뿐만 아니라 데이터 관리의 특정 측면을 살핌

• 표준 및 규정 준수: 외부 프로젝트 환경과 연관

• 프로젝트 환경: 내부 프로젝트 환경을 검사

각 프로젝트 차원은 1 (단순)에서 4 (복잡)까지의 값의 정의뿐만 아니라, 1에서 4까지의 범위에 눈금을 부여 받는다. 이는 프로젝트 차원이 프로젝트 자체 평가의 시각적인 표현을 생성하는 데 사용될 수 있음을 의미하며, 아래 그림에 나타낸 바와 같이 Kiviat 다이어그램을 사용한 것이 그 예이다.

모든 Ignite | IoT 프로젝트 차원의 정의가 포함된 Excel 스프레드 시트는 온라인으로 이용 가능하다. 또한 다른 차원들의 보다 더 상세한 정의는 이후 “빌딩 블록” 부분에서 제공된다. 아래 그림에 나타난 바와 같이, 이 단계에서 프로젝트 차원의 주 목적은 프로젝트에 대한 그들 스스로의 평가 (자기 평가)를 수행하는 프로젝트 관리자를 도와 체크리스트를 제공하는 것이다. 결과는 솔루션 아키텍처 및 설계 결정을 위한 투입뿐만 아니라 중요한 영역과 프로젝트 위험을 확인하는데 사용될 수 있다. 또한, Ignite | IoT 팀은 현재 그들의 자기 평가 결과를 우리에게 제공 한 다양한 프로젝트의 데이터베이스를 구축하고 있다. 이는 프로젝트 관리자가 다른 사람들의 것과 자신의 프로젝트를 비교하고, 얻은 교훈으로부터 혜택을 누릴 수 있게 한다.

                          IoT Project Dimensions
                          

수량 구조

모든 솔루션 설계와 마찬가지로, IoT 프로젝트는 수량 구조를 필요로 한다. 수량 구조는 밀접하게 사업 이해관계자의 요구 사항에 부합되어야 하며, 주요 영역에 계획된 성장을 보여주어야 한다.

IoT의 관점에서, 이 영역들은 다음을 포함한다: 시간이 지남에 따라 자산의 수, 자산에서 백엔드로 보낸 사건의 수, 사용자 수 (총 사용자 수 및 동시 사용자 수), 연간 프로세스 인스턴스의 수 (자산 활성화, 사건 등 핵심 과정). 이 정보는 솔루션 설계자에게 매우 중요할 것이다.

                              IoT quantity structure
                              

이정표 계획

마지막으로, 일반적인 프로젝트와 마찬가지로 IoT 솔루션 프로젝트의 초기 솔루션 설계는 이정표 계획을 포함해야 한다. 이 계획은 일부 정상적인 이정표와 일부 IoT에 특화된 이정표를 포함한다.

• 생산 또는 구매 의사결정

• 공급 업체 선정

• 시제품

• 모의/현장 테스트

• SOP /생산 시작 (하드웨어)

• 백엔드 솔루션의 초기 출시

마일스톤 계획을 구조화 할 때, 자산 구성 요소를 위한 하나와 백엔드를 위한 하나, 두 개의 별도 타임라인을 가질 수 있도록 할 수 있으며, 이는 이들간의 주요 의존성을 포함하도록 한다.

이 문서의 번역:
i.분석_예상_계획.txt · 마지막으로 수정됨: 2015/09/15 17:49 저자 wikiadmin
CC Attribution-Share Alike 3.0 Unported
Powered by PHP Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0 Valid HTML5