IoT 기반 사업 모델로의 이행의 효율적 관리는 많은 회사들에 점점 중요해지고 있다. 새로운 IoT 솔루션의 시행과 현존 제품이 IoT를 가능하게 하는 것은 프로젝트 수준에서 일어나는 반면 이 이행을 위한 전략은 기업 수분에서 정의되고 관리될 필요가 있다.

우리의 경험에 기반한 사례 연구의 분석과 많은 전문가 인터뷰는 이 책의 Part I에 나와있다 우리는 IoT 전략 관리와 프로젝트 수행 모두의 모범 경영 사례를 수집했다. Ignite | IoT 방법론은 이들 모범 경영에 기반하고 두 부분으로:

• Ignite | IoT 전략 수행: 기업들이 그들의 IoT 전략을 정의하고 IoT 도입을 위한 조직을 준비하는 것을 돕는다. IoT 전략을 지원하기 위한 IoT프로젝트의 포트폴리오를 만들고 관리하는 것을 지원한다. 주로 COO, CTO, 협력 전략, 제품 포트폴리오 관리와 관련된다.

• Ignite | IoT 솔루션 인도: IoT 솔루션 프로젝트의 계획과 실행에서 제품 관리자와 프로젝트 매니저를 지원한다. 계획을 다루고 만들고 IoT 프로젝트 단계의 단계를 가동시킨다.

                          Ignite | IoT Methodology Overview
                          

많은 대기업들은 파괴적인 패러다임 전환을 다루는 것이 극도로 어렵다는 것을 발견한다. 이는 새로운 발견이 아니다. 1942년, Joseph Schumpeter는 “자유시장의 발전을 인도하는 난잡한 방식”을 묘사하기 위해 모순되는 것처럼 보이는 용어 “창조적 파괴”를 만들어냈다[EC1] (실제로, 이는 카를 마르크스의 작업으로 거슬러올라갈 수 있지만, 그러지는 말자…..). 아마도 파괴적인 기술을 다루지 못한 회사의 사례 중 가장 많이 인용된 것은 코닥이다. 코닥이 디지털 사진의 발명자 중 하나였음에도, 그 회사는 필름 기반 사진의 지도자에서 새로운 디지털 사업모델로 자신을 변화시키는 데 실패했다. Schumpeter’의 웃음은 많은 대기업이 직면하는 딜레마의 완벽한 요약 같다– 내부에서 스스로를 재발명하는 능력이 없음과 페이스 신규 업체가 새로운 디지털 사업을 그린 필드에서 창조하는 극단적으로 빠른 속도다.

어떤 사람들이 “코닥 모멘트”라는 단어를 사용함에도, 우리의 시각에서는 코닥의 역사에 그런 구별되며 결정적인 모멘트는 없었다 – 회사의 쇠퇴는 10년도 더 걸렸고 다양한 여러 이유가 있었다. IoT의 맥락에서, 모든 회사는 IoT가 나타내는 잠재적으로 파괴적인 패러다임 전환이 어느 정도인가, 그리고 얼마나 이 전환이 각자의 수직 시장에서 길게 걸릴 것인가에 대해 자문해야 한다. 이들은 완전히 Ignite | IoT 전략 실행 방법론이 다루고자 하는 것의 문제이다: 변화하는 IoT 로드맵이 개별 회사에 어떻게 보이는가와 어떤 IoT 기회의 포트폴리오가 관리되어야 하는가를 배우는 것과 개별 IoT 계획이 확인되고, 승인되고 실행될 수 있는가에 대한 더 나은 이해를 만드는 것이다.

이제, 우리는 많은 CEO들이 이 책을 읽고 직접적으로 Ignite 방법론을 그들의 IoT 전략에 적용하기를 기대하지 않는다. 하지만, 많은 관리자들은 이 부분에서 그들의 상황에 적용할 수 있고 최고경영층에 영향을 주는데 쓰일 수도 있는 발상을 얻을 것이다. 그리고 아마 더 중요하게도, 우리는 프로젝트 수준에서 일하는 많은 사람들에게 어떻게 그들의 발상을 더 잘 팔 고, 예산을 받고, 일반적으로 IoT 프로젝트의 낙찰의 보장 관리할 수 있을지에 대해 질문 받을 것이다. 이런 종류의 상황에서, 어떻게 자신의 IoT 사업 사례를 구축하는가 뿐 아니라, 어떻게 이 사업 사례가 다른 사업 기회의 맥락에서의 관리에 의해 보여지는 지-그리고 어떻게 자신의 사업 사례를 성공적으로 팔 수 있을지도 중요하다.

우리가 이 부분에서 논한 것의 대부분은 복잡한 제품 포트폴리오를 가지고 큰 산업 회사들을 위해 일하는 우리의 “machine camp” 에 더 흥미를 가질 것이다. 하지만, 우리의 이 공간의 많은 재임자를 위해 일하는 “Internet camp” 의 사람들도 관심을 가질 것이다.

아래의 그림은 여섯 분야로 나누어지는 Ignite | IoT 전략 실행 뼈대의 주요 요소를 요약한다: IoT 전략, IoT 기회 확인, IoT 기회 관리, 계획, IoT 최고기관, IoT 플랫폼.

                      Ignite | IoT Strategy Execution Methodology
     

회사의 IoT 전략은 그들이 IoT를 향해 전환하려는 규모와 속도를 반영할 필요가 있다: 회사가 실패의 위험을 무릅쓰고 선구자가 되어 빠른 시장 점유율을 얻으려 하는가? 아니면 후발주자가 되어 고객이 수용하고 구입하리라는 확실성이 있을 때에 새로운 IoT 솔루션을 실행하려 하는가? 어떤 회사들은 IoT를 그저 바로 지금 일어나는 많은 패러다임 전환 중의 하나로 간주하고 IoT 도입에 제한된 자원만을 투자한다. 다른 회사들은 IoT를 다음 10년간의 근본적인 패러다임 전환으로 보고 지대한 영향을 가져올 내부 변롸 관리 프로그램의 설립과 병행하여 IoT 프로그램에 많은 투자를 한다. IoT 전략은 비전, 목표, 원칙의 지시를 제공할 필요가 있다. 또한 어떻게 IoT 관련 사업 분야에서 전략 동맹과 파트너 생태계가 발전되어야하는가에 대한 높은 수준의 설명을 제공해야한다. 마지막으로, 예산 계획과 IoT 로드맵 관리에 더해, IoT 기회와 프로젝트의 포트폴리오를 관리할 필요가 있다.

IoT 솔루션의 혁신적 발상의 생성인 IoT 기회 확인, 은 피고용인, 고객, 개발자의 혁신적 잠재력을 끌어내는 개방된 과정에서, 혹은, 발상이 회사의 가치 체인 같은 주어진 맥락에서 도출되는 더 구조적인 접근법에서 일어날 수 있다. 가장 많은 장래성을 보이는 발상은 발상의 개선을 위한 견본을 사용하는 등 더 자세하게 상술되어야 한다.

첫 품질 관문을 통과하여, 가장 장래성 있는 발상이 IoT 기회 관리 단계의 일부로 개선된다. 실현가능성과 사업 사례에 접근하기 위해 더 상세한 사업 모델이 준비되어야 한다. 다음의 Impact & Risk Assessment 단계는 사업모델의 충분한 고려가 있다면 모든 가능한 결과를 보장한다.

한번 IoT 기회가 승인되면, 계획 단계로 넘어간다. 이 단계에서, 관리자는 계획을 세우기 위한 최선의 방법을 결정해야 한다; 예를 들면, 전용의 내부 프로젝트처럼, 스핀오프처럼, 심지어는 M&A 프로젝트처럼 말이다. 내부 프로젝트에는 이들 활동들 인터페이스는 Ignite | IoT 솔루션 인도 방법론이다.

IoT 최고 기관IoT Center of Excellence (CoE)은 ioT 컨설팅과 관리 지원의 변화를 통해 새로운 프로젝트가 탄력을 빠르게 얻도록 도울 수 있다. IoT 성숙기 평가는 조직이 현재 IoT 도입의 면에서 어디에 서 있는지 더 잘 이해하도록 도울 수 있다.

마지막으로, 큰 조직이 다양한 프로젝트에 솔루션을 개발하기 위해 사용될 수 있는 공유된 IoT 플랫폼을 제공하는 것은 이치에 맞을 수 있다. 이는 보통 IoT 어플리케이션 플랫폼, 연결성 솔루션, 기술적, 기능적 표준을 포함한다.

다시, 우리는 IoT에 진지하게 임하는 모든 큰 조직이 위의 요소들을 완전히 개발해야 한다고 말하는 것이 아니다. 사실, 우리가 신규 업계의 사람들에게서 받은 몇몇 반응은 어느새 “와, 너희 기계 사람들은 상자랑 화살표가 들어간 구조화된 플로우 차트를 보면 정말 더 잘 느끼는구나, 그렇지?” 였다. 이는 신규 업체들의 시각에서 보면 공정한 평가일 수 있다. 하지만, 전략 협력에서 더 큰, 다양한 이해당사자 기관들의 사람들의 동의를 얻는 것의 중요성은 과소평가될 수 없다. 그리고 이 전략을 효율적으로 소통할 수 있게되는 것은 이 목표를 위한 중요한 첫번째 발걸음이다.

다른 통고는 위의 “IoT 전략”의 일반적인 본질과 관련된다. 대기업들은 보통 이미 기업의 전략 관리와 포트폴리오 관리 과정들, 다양한 CoE들, 공유된 IT 플랫폼 등을 설립해왔다. 그래서 대부분의 경우 이들 설립된 구조와 어떻게 그들이 Ignite | IoT 전략 실행 방법론에 묘사된 다양한 요소들을 도입할 필요가 있을 것인가를 보는 것이 필요할 것이다. 그러나, 우리는 그들을 여기서 포괄적인, IoT 중심적 시각에서 묘사할 가치가 있다고 믿는다. 그리하여 개개 조직은 그들의 수요에 기반해 쉽게 적응할 수 있을 것이다.

관리 수준에서, 대답해야 할 첫번째 질문은 “얼마나 진지하게 우리가 이 IoT 선전을 받아들여야 하는가?”이다. 정말로 가장 중요한 파괴적인 힘이 수년 내에 우리의 사업을 변화시킬 것인가, 그것은 그저 그다지 중요하지 않은 많은 것들 중 하나가 아닌가? 크고 고도로 분화된 회사에서, 이 질문에 대한 답은 사업 부문마다 다를 수 있다. 더욱이, 그 질문은 IoT에 대한 질문의 형태로 오지 않을 수도 있다. 그것은 “커넥티드 차량이 나에게 OEM으로서 얼마나 중요할 것인가, 그리고 내 사업에 언제 영향을 미칠 것인가?”같은 질문으로 올 것이다. 혹은 산업 장비 회사가 “전체 서비스화 전략의 맥락에서 커넥티드 서비스의 전략적 중요성이 무엇인가?”라고 물을 수도 있다. 어떤 CEO들은 이런 질문에 대답하기 위해 관리 컨설턴트 회사를 실제로 고용하고 다른 이들은 경험과 감에 근거한 내부 관리계와 함께 결정할 것이다.

중요해 보이는 것은 이들 질문, 그리고 질문에 대한 답이 명쾌하게 연결되어있으며, 관리 팀이 비전, 목표, 원칙 지시를 도출해낼 수 있는 단단한 토대를 형성한다는 것이다.

이 비전은 다음과 같은 것들을 포함할 수 있다:

• ACME 산업은 순수한 제품 사업에서 커넥티드 산업 서비스의 시장 선도 제공자로 스스로를 변화시킬 것이다

• ACME Automotive 는 스스로를 개방 커넥티드 차량 어플리케이션 플랫폼의 선도적인 공급자로 확립시킬 것이다

이는 일련의 더 단단한 목표와 사업 목적과 동반되어야 한다 예를 들면:

• X, Y, Z의 제품 분야에서, 우리는 커넥티드 서비스에서 X%의 이윤을 창출할 것이다

• P, Q, R의 제품 분야에서 우리는 커넥티드 서비스에 기반해 유지비를 X% 줄일 것이다

일련의 주요 전략과 가이드라인은 다음을 지원해야 한다:

• ACME Corp는 주요 기회를 확인하기 위해 전략적 가치 체인 분석과 결합시켜 내부의 IoT 중심인 개방적 프로그램을 확립해야 한다

• ACME Corp는 상위 10개 IoT 기회에 X백만 달러를 투자하기로 배정할 것이다

• 내부와 외부 프로젝트의 분리와 M&A 중심 활동은 개개 사례의 분석결과에 따라 X%에서 Y%까지가 되어야 한다

• PQR 분야에서 우리가 플랫폼을 통제하고 A, B, C같은 선택된 파트너에게만 허용하는 반면 XYZ의 분야에서, 우리는 개방 파트너 생태계를 건설해야 한다 •

고위 간부는 또한 일련의 전략과제에 개인적 책임을 져야 한다. 예를 들면:

• CEO는 연간 예산 처리를 IoT 우위를 반영하도록 바꿀 것이다

• CEO는 파트너십 논의를 시작하기 위해 파트너 A, B, C와 접촉할 것이다

• CFO는 새로운 IoT 전략에 X%의 M&A 예산을 할당하기 위해 그들의 M&A팀과 함께 일할 것이다.

전체 전략 뼈대가 정해지면, 다음 질문은 이것이다: 어떻게 우리가 이 모든 것을 견고한 기회로 분해할 수 있는가? OEM이 그들이 커넥티드 차량을 주요 전략으로 추구하기를 원한다는데에 동의했고 그 전략에 전반적으로 대량의 자원을 할당하기로 했다고 하자. 우리가 Part I에서 보았듯이, 커넥티드 차량은 많은 커넥티드 수평 계획에서 공동체 기반 주차까지 다양한 관련 기회가 있는 매우 넓은 개념이다. 그리고 아마도, 아직 발견되지 않은 더 많은 장래성 있는 기회가 이 분야에 있을 것이다. 그러므로 커넥티드 차량을 전략 분야로 결정한OEM이 어떻게 가장 좋은 기회가 확인되었고 결과 투자되었다고 장담할 수 있겠는가?

도움이 되는 첫번째 것은 어떤 종류의 기회가 IoT의 맥락에서 기대되고 있는가에 대한 조직 내 합의에 이르는 것이다. “우리가 연결할 수 있고 약간의 서비스를 더할 수 있을 것 같은 게 뭐가 있는지 보자”같은 질문은 유용한 접근법이 되지 못할 것이다. 대신, 확인되어야 할 가장 그럴듯한 범주나 기회에 대한 개관을 제공하는 것은 도움이 될 것이다. 예를 들어, 아래의 표는 새로운 사업과 내부 개선을 최고 수준에서 차별화한다. 이들 두 영역 각각은, 관리 개선이나 데이터 중심 사업 모델 같은 많은 일반 범주들이 정의되고, 몇몇 전형적인 KPI와 그 예시들과 함께한다. 당신의 사업 영역에 이 예시를 적용하는 것은 최고의 IoT 기회 탐색을 구조화하는데 도움이 될 것이다.

                       IoT Opportunity Categories (Source: own diagram)
                       

다음 단계는 대기업에서의 발상 생성 과정을 관리하는 것이 이용가능한 다른 옵션들을 이해하는 것과 어떻게 이들 옵션을 IoT 사업 기회의 생성에 가장 잘 적용하는가이다. 보통 대기업에서 발상을 만들어내는 두 주요한 방법이 있다: 개방된 발상 생성(그린 필드 접근법)이나 발상이 어떻게 그들이 회사의 현재 가치 명제와 연관되는가와 같은 주어진 맥락에서 진화하는 더 구조화된 발상 생성 접근법이다. 후자의 접근법은 보통 상의하달식 과정으로 조직된다. 그것은 파트너 생태계와 잠재적인 회사에의 IoT의 영향과 심지어는 산업의 가치 체인을 포함하는 시장의 분석조사를 수행하는 내부 전략 팀이나 외부 컨설팅 회사를 포함한다.

개방된 발상 생성은 일반적으로 더 파괴적인 발상을 만들어낸다. 회사들은 그러므로 이들 발생을 모으기 위해 다양한 채널을 가져야 한다; 피고용인, 고객, 심지어는 개발자 같은 채널을 말이다.

사례: Bosch Web 3.0 Platform

Bosch는 “Web 3.0 Platform”이라고 불리는 웹 기반 관념화 플랫폼을 실행했다. 이는 Bosch 피고용인들(혹은 별개 조직들)이 발상을 입력하고 투표할 수 있게 한다. 빠른 스캔은 처음 입력된 발상의 초기 등급을 제공하는 입력과 필터 방법이다(시장 평가, 이윤과 이용가능성). 핵심 팀(Bosch 기업과 사업부문의 피고용인들)은 주제 전문가들과 발상에 더 상세하게 접근하기 위해 워크샵에 집중한다. 보통, Osterwalder 캔버스는 사업 모델을 선택된 발상을 위해 원안을 그리는 데 사용된다. 다른 품질 관문을 지나면서, 프로젝트는 수립된다. 이 과정에서 더 자세한 것은, “Business Model Development”와 “Organizational Setup”을 보라.

지금까지, 데이터베이스(18개월 동안 수집된)에는 커넥티드 차량과 관련된 600개 이상의 발상이 있으며, “360도 주차”같은 첫번째 구체적 프로젝트는 시작되었다. 우리는 웹 3.0 플랫폼의 책임자인Bosch 대표자들에게 그들의 플랫폼에 대한 경험을 요구했다. Peter Busch, Senior Expert at Bosch Corporate Research 는 회사의 사업 계획이 이미 구식이 되고 한 발상이 특정 품질 관문에 도달했을 때에프로젝트 팀이 직면한 과제에 대해 말했다. IoT 발생을 위한 “기회의 창문”은 더 이른 시기에 정해진 회사의 사업 계획과는 나란히 설 수 없다. 인터넷 기반 제품 라이프사이클(개발 기간을 포함하는)은 이런 적용가능한 전통적인 모바일 분야의 제품들보다 더 짧기 때문에, 이 조정 문제는 더 어려웠다. 한편으로는, IoT 발생을 빨리 생산하라는 큰 압력이 있었고, 다른 한편으로는 대기업들이 특히 더 긴 계획과 개발 시기를 가졌다. 그는 문제를 야기하는 IoT 특유의 측면을 덧붙였다: IoT는 여러 영역을 건드림으로서 횡단 맥락을 개방한다; Bosch 사업체의 수직 초점과 모순되는 어떤 것. “IoT 발상은 종종 여러 사업체와 관련되기 때문에, 모든 맞는 사람들을 태우기가 어렵다,”고 Embedded Software & Connected Services at Bosch 의Senior Expert인 Sven Kappel 이 설명한다. 프로젝트 성공의 주요 요소는 각각의 다른 전략에도 불구하고 그들의 참여를 조정하기 위해 사업체들의 공통 관심사를 확인하는 것이다.

Sven이 확인한 다른 문제는 조직이 항상 시일 내에 발상을 확인하고 개발할 능력이 있지는 않다는 사실과 연관된다. 이는 그러므로 오픈 소스 커뮤니티나 사업 인큐베이터로서 2014년 설립한 Bosch Startup Platform (BOSP) 같은 자원을 찾는 새로운 방식을 요구한다.

피고용인 인센티브

고려해야 할 다른 중요한 점은 어떻게 당신이 회사의 절차를 개선하고 새로운 솔루션을 나오게 하는 지속적인 혁신을 당신의 피고용인들 사이에서 고무할 수 있는가에 대한 질문이다.

혁신과정에서 피고용인들을 참여시킬 좋은 이유들이 있다: 그들은 그들이 봉사하는 최종 사용자와 고객들에 더 밀접하여 그들의 수요에 대해 더 많은 지식을 축적할 수 있다. 그에 더해, 그들은 보통 “사일로 멘탈리티”의 위험을 줄이는 여러 기능, 순위, 위치를 대표한다.

큰 조직에는 피고용인에게 인센티브를 제공하는 자리잡은 프로그램이 있다. Siemens 3i – Program (3 i는 “Ideas, Impulses, and Initiatives”를 나타내며, 그 이름은 1997년에 설립된 제안 제출 시스템에 주어졌다)이 그러한 예시이다: 피고용인들은 새로운 서비스나 절차 개선에 대한 그들의 발상을 제출할 수 있고 연간 10%의 절약된 비용을 받는 한 예시처럼 성공시에는 금전적 보상을 받는다. 독일에서는, 100,000개 이상의 발상이 매년 3i-Program에 제공된다[SI1].

Managing Partner at five i`s innovation consulting GmbH인Peter Fürst에 따르면, 돈은 분명히 인센티브만이 아니며 케어와 함께 다루어져야 한다. 특히 새로운 제품과 새 사업의 발상에서는, 발상의 인정 및 가시성과 공적이 동기를 더 지속가능하게 지원한다. Peter Fürst는 인센티브나 인정 기반 시스템에서 혜택을 받아야 하는 것은 발상의 제출자만이 아니라고 믿는다: 많은 발상이 한 사람 이상의 자극에서 자랄수록, 이 모든 창작자의 발상의 성취는 명예로워야 한다. 그렇지 않으면 사람들은 다른 사람이 발상을 훔쳐서 먼저 제출하는 것을 두려워하여 그들의 발상에 대해 상호작용하는 것을 그만둘 것이다. 그런 분위기에서, 창의성은 지원되기는커녕 끝장나게 된다.

이를 다루는 한 가능한 방법은 멤버들에게 흥미로운 무역 박람회와 회의에 참가할 기회를 주는 등 지속적인 교육과 사회 네트워크면에서 매력적인 혜택을 제공하는 “혁신 클럽”을 설립하는 것이다.

많은 좋은 발상들은 처음 품었을 때에는 그리 좋아보이지 않는다. 그들은 가능한 이해 당사자들을 정말로 설득하기 전에 자라도록 돌봄을 받고 성숙해질 필요가 있다. 운이 좋게도, 발상 개선에 지원을 제공하는 관념화 방법론에는 부족함이 없다. 이 점에서, 우리는 유용함을 알게된 두 방법을 강조할 것이다.

첫번째 접근법은 St. Gallen Business Model NavigatorTM 이다[BM1]. St. Gallen 대학(USG)은 다른 종류의 사업 모델들과 그들이 성공한 이유들에 관해 아주 넓은 연구를 수행해왔다. 250개 이상의 사업모델의 분석에 기반해, USG는 새로운 사업 모델의 구축에 적용될 수 있는 일련의 대표적인 사업 모델 패턴을 확인했다. USG는 이제 대학에서 열린 정기 워크샵 동안 새로운 사업 발상을 개선하는데 사용될 수 있는 다양한 사업 모델 패턴을 상세하게 묘사하는 한 세트의 카드를 제공한다. USG가 행한 IoT 전문 사업 모델에 대한 연구와의 결합으로 이것은 이제 사업 모델을 창조하고 개선하는데에 강력한 도구이다.

발상 개선을 위한 다른 흥미로운 도구는 five i’s innovation management GmbH 가 개발한 Innovation Project Canvas이다[IP1]. Innovation Project Canvas는 본래의 Osterwalder Business Model Canvas를 확대한 것이며 스마트 가정 적용 영역 같은 IoT 개념에 적용가능하다는 것이 이미 입증되었다. 아래 그림은 개관을 보여준다.

Innovation Project Canvas with AIA (Source: five is innovation management, 2014)
                       

이 the Innovation Project Canvas 에서 특별히 유용한 것은 그것이 세 단계로 나누어 작용한다는 것이다. 처음에는, 학제간 팀은 가능한 소비자 그룹에 대해, 그리고 강렬한 가치 문제를 개발하는데 집중한다. 팀은 그것이 목표 그룹(들)에 막대한 이익을 제공할 수 있다는 확신이 들 때까지 발상을 개선한다. 둘째 단계에서, 팀은 가치 문제와 사업 모델을 인도할 수 있는 가능한 솔루션을 논의한다. 다시, 이 단계의 결과는 수정되고 더 개선된다.

마지막으로, 세번째 단계에서, 재빠른 개발 전략이 계획된다. 팀은 가장 중요한 미지의 것이나 위험을 확인하고, 다음 단계의 개발에서 이들을 다루는데 집중한다. The Innovation Project Canvas는 미래 프로젝트 팀의 모든 주요 멤버들을 프로젝트의 목표와 내용에 관한 공통의 이해를 촉진하기 위해 접촉시킨다. 적절한 사업 모델이 있는 매력적인 가치 문제의 통합된 개발은 발상의 진정한 잠재력을 빠르게 밝혀내고, 열광하는 고객을 끌어들이며, 팀 멤버 개인의 지불 금액을 늘린다.

상세한 발상 스케치인 발상 개선 단계의 결과는 다음 품질 관문에서 프레젠테이션에 사용될 수 있다. 승인된 후에는 사업 모델 개발에 사용될 수 있다.

Bosch에서, QuickScan 방법은 기회에 자격을 주고 선택하기 위해 사용되었다. Bosch Corporate의 Strategic Marketing Manager인 Silke Vogel은 설명한다 이 방법을 다음과 같이: “ QuickScan 방법은 “금이 든 항아리”로 이끌어 줄 장래성 있는 사업 발상을 빠르게 확인하기 위한 수단으로서 웹 3.0 핵심 팀 멤버들에 의해 개발되어왔다. 그 방법은 우리의 시점에서는 성공 이야기를 만들어내는 열쇠인 세 주요 요소에 집중한다: 시장 매력, 기술 가능성, 적합성이 그들이다. 이 세 주 요소를 위해, 특정한 하부기준들이 다섯 포인트 스케일과 상세한 설명을 사용해 알아보게 된다. 이 방법으로, 모든 핵심 팀 멤버들이 사업 발상을 공통 이해에 기반하여 각 사업 발상을 다른 것과 비교하여 최종 점수를 매기며 양방향으로 평가한다.”

보통, 한 발상이 첫 품질 관문을 통과한 뒤에는, 투자하기에 매력적인 견고한 사업 사례 문서를 만든다는 목표를 위해 작은 팀이 발상의 개선과 입증을 위해 소집된다. 일반적으로, 작은 팀은 결정을 내릴 투자 위원회에 발표하기 전에 IoT 사업 모델에 수주, 혹은 수개월간 공을 들인다. 만약 모든 IoT 계획이 유사한 IoT 사업 모델 접근법을 따른다면, 다양한 제안들을 비교하고 순위 매기기가 더 쉬울 것이다.

Bosch에서는, IoT 사업 모델을 개발하는 프로젝트 팀들은 영역 전문가, 사업 모델 코치, 마케팅 컨설턴트같은 다양한 능력을 가진 피고용인을 포함한다. 이 조직상 파견과 발상에 관해 처음부터 열정적인 리더를 모두 가지는 것은 매우 중요하다. 다른 성공요인은 “podular” 조직 구조이다. Silke Vogel은 설명한다 그것이 의미하는 바를: “자주적으로 참여하는 고도로 동기부여되고 열정이 있는 팀 멤버다. 그들은 더 결정적인 힘을 가지고, “사내기업가”방식으로 행동하며, 고객에 더 가깝다. 또한 대기업의 확립된 구조와 경쟁력에서 혜택을 받는다.. 이는 그들이 더 빠르고 효율적이 되게 만든다.”

확립된 사업 모델 캔버스는 실제로 특정한 IoT 사업 모델을 다루지는 않기 때문에, Bosch의 팀은 사업 모델 개발을 위한 IoT 전문 접근법을 개발해왔다. Bosch Software Innovations에서 이 팀의 관리자인 Veronika Brandt: “복잡한 가치 체인의 파트너 생태계 복잡성 같은 IoT 전문 측면을 다루는 것은 IoT에 매우 중요하다. 이는 사업 모델이 분명히 연결된 파트너 가치 제안을 필요로 한다는 것을 의미한다. 다른 IoT 전문 측면은 커넥티드 사물에서 나온 데이터와 이 정보로 만들어진 서비스의 사용이다. 이 때문에, 우리는 Osterwalder canvas 의 확장인 IoT Business Model Builder 를 개발했다. 기회 관리 단계에서, 그것은 사업 모델의 구성요소를 정의하는 과정에서 가이드로 작용한다. 보통, 입력은 다듬어진 발상이며 출력은 사업 사례이다.”

        IoT Business Model Builder (Source: Bosch Software Innovations, 2015)

IoT Business Model Builder의 주요 구성요소는 다음 부분에 정의된다. 집을 짓는 것처럼 우리는 바닥부더 시작한다:

• 전략 묻기: 이 단계는 사업모델의 기초를 세우고 IoT 전략이나 기업의 ioT 비전의 지지를 보장한다. 이는 강령에서 사업 모델의 목표를 정의하고 그 중단기 목표의 윤곽을 그린다. “미래보장”의 수행은 어떻게 사업 모델이 미래 과제를 다룰 것인지를 나타내어야 한다. 이는 어떻게 핵심 기능(사업 모델이 모방되는 것을 어렵게 하는)과 미래 변화에 대한 반응성 같은 차별성의 개발을 조성할 것인지에 대한 생각들을 포함한다. 전략 묻기는 또한 제공된 것에 대한 짧은 설명을 포함한다.

• 가치 제안: 고객을 위한 공급의 매력을 향상시키기 위해, 타겟 그룹을 분할하고, 가치 제안을 다듬고, 고객 채널을 정하는(애프터 세일즈의 의식부터 고객 여정에서의 모든 접점에서의 고객을 위한 인터페이스) 믿을 수 있다고 증명된 접근법이 채용될 수 있다. IoT 솔루션들이 종종 강한 파트너 생태계에 의존하기 때문에, 가치 제안은 파트너를 고객과 같은 정도로 존중해야 한다. 첫째, 파트너가 이미 정해지지 않지 않은 이상(전략 파트너십이나 관계가 존재하지 않는다면), 그들의 역할은 정해질 필요가 있다(정보 제공자, 브로커 사업자). 그리고, 우리는 각 파트너 역할(혹은 후보)의 파트너 가치 제안의 윤곽을 그리며 “그들에게 어떤 이익이 있는가”를 정할 필요가 있다. 마지막으로, 예를 들면(고객이 채널로 정해질 수도 있다) “다른 파트너들과 마찬가지로” 파트너 채널이 정해져야 한다.

• 고객 여정: 고객의 관점에서 양단간 솔루션을 설명하는 것은 고객이 적절하다고 생각하는 제공된 것의 요소를 강조하는데 도움이 된다. 여기, 제공된 것의 실제 사용자/고객에 집중하는 것은 만약 이것이 당신의 고객이나 고객의 고객이라는 것과 상관없이(B2B2C 솔루션에서) 적절하다. 고객 여정을 정의하는 것은 다른 긍정적 효과가 있다: 그것은 고객이 확인해온 모든 적절한 채널을 확실하게 하고 이들은 여정의 모든 단계에서 애프터 세일즈를 인지하며 고객 접점에 봉사한다.

• 부가가치: 한번 솔루션이 정해지면, 부가된 가치는 실증될 수 있다. 부가 가치의 핵심 요소는 이해당사자 네트워크다. 이는 관련 당사자(기업, 파트너, 고객)를 접속점으로 보여주고 가치와 서비스 흐름을 이들 접속점 사이에서 보여주는 플로우 차트에 보통 묘사된다. 네트워크의 구성 요소는 당사자의 능력이다: 그들은 솔루션을 지원할 수 있는 기술, 자원, 노하우의 혼합이다. 능력 자산은 어떤 접속점이 특정 서비스를 인도하는데 가장 적합한지 정하는 것을 돕는다. 한번 네트워크가 정해지면, 이 접속점이 무슨 커넥티드 사물을 관리하는지, 어떤 부가가치 정보(혹은 커넥티드 사물에서 나온)를 인도하는지, 어떤 서비스를 인도하는지가 각 접속점에서 잡혀야한다.

• 사업 사례: 한번 부가가치가 정해지면, 사업 사례를 계산하기는 쉽다: 가장 가격에 관련되는 측면은 부가가치 단계에 나타나고 추정 이윤은 고객과 파트너 가치 제안에서 취해져야 한다. 관련된 정당한 접근법은 네트워크에 관련된 모든 당사자를 가로지르는 솔루션 소유권의 총 비용(TCO)을 계산하고 이해당사자간에 공평한 방식으로 수익을 배치하는 수익 모형을 정하는 것이다. 이는 모든 관련 당사자 간 투명성을 요구하며 이는 IoT 생태계에서 신뢰와 전략적 파트너십의 중요성을 다시 한번 강조하는 것이다. 사업 사례 계산에 사용될 수 있는 여러 기술과 견본이 있지만, 우리는 모든 IoT 계획을 통틀어 사업 모델을 쉽게 비교할 수 있게 해주는 조화를 추천한다.

• 사업 영향과 차후 사업 모델: 우리의 다이어그램에서 집의 굴뚝은 사업 사례와의 결합에서 보아야 할 사업 모델의 두 금전적 효과를 나타낸다. 예를 들면, 만약 사업 사례가 장래성이 있는 것 같지 않지만 회사가 사업 모델을 새 시장에 진입하거나 새 기술에 접근하기 위해 시행할 필요가 있다면, 이들 전략적 측면은 기록되어야 한다. 두번째 굴뚝, “차후 사업 모델”은 매우 IoT 특유의 것이다: 사업 모델을 정하고 커넥티드 기기로 모든 관련 데이터를 얻었을 때, 팀들이 어떻게 데이터를 개선할지(가령, 새로운 부가가치 정보와 결합시키거나)에 관한 새로운 발상을 내놓고 새로운 서비스를 만들어내는 일은 매우 흔하다. 어떤 발상들은 같은 사업 모델안에서는 개선될 수 없고 분리된 사업 모델에서 개발이 가능하다. 하지만, 그들은 자신들이 만들고 있는 사업 모델을 볼 필요가 있다.

파트너 생태계

IoT 파트너 생태계 개발에 관한 다음 조언은 Bosch Software Innovations 의 Director Partner Management 인 Anuj Jain에게서 나온 것이다:

IoT 가치 체인은 길고 넓며, 물리적 자산, 운영 서비스, 디지털 서비스를 망라한다. IoT 계획을 주요 고려사항은:

• 주어진 현재 능력을 실제로 인도할 수 있는 가치 체인의 요소는 무엇인가? • IoT 가치 체인 생테계에서 하나의 요구를 통제할 수 있는가? 실제로, 어떤 개별 회사가 IoT 가치 체인의 모든 측면에 전문화되는 것은 가능하지도 합리적이지도 않다. IoT 계획에서, 바른 전략은 비전, 열정, 목적을 공유하는 파트너 생태계이다. 이는 합리적인 비용으로 IoT 프로젝트의 성공에 필수적인 요소인 전문가 노하우와 전문기술에 빠른 접근을 허용한다. 잘 만들어진 파트너 생태계는 시장에 시간을 가속시키고, 각 이해당사자의 투자회수(ROI)를 향상시키며, 고객 경험을 개선한다. 그것은 또한 고객에게 그들의 투자가 전체 가치 체인에서 지속적인 지원과 혁신을 가질 것이라고 보장한다.

역사적으로, Daimler, Airbus, Microsoft, IBM 같은 오직 큰, 자리잡힌 베히모스가 파트너 생태계를 만드는 데 노력했다. 이들 사례에서, “베히보스”는 일반적으로 막대한 영향력을 행사하고 종종 생태계의 성격을 결정하는 생태계의 중심이었다. IoT는 부가가치 파트너 네트워크 및 조직 협력의 생태계를 대중화하고 있으며 이느 경쟁우위를 가져올 것이다. 대기업과 작은 기업 모두 유기적으로 떠오르고 더 평등하고 협력적인 파트너로 이끄는 더 확산된, 덜 중앙집권적인 생태계에서 성공적으로 일하고 있다.

성공적인 생태계의 대중적인 몇몇 사례를 보자:

• 가장 먼저 떠오르는 것은 애플과 음악 산업의 예이다. 음악 산업은 자산(음악 저작권)을 보유한다. 스티브 잡스는 음악을 팬들에게 제공할 합법이며 감당할만하고 쉬운 방법을 제공할 기회를 발견했다. 애플은 플랫폼을 만들어냈고 잘 운영했다(운영 서비스와 디지털 서비스). 애플은 생태계를 통제하는데 성공했다.

• 흥분되는 사례는DriveNow다. BMW 는 위대한 자동차(물리적 자산)를 제조한다. Sixt는 확장된 경험과 경쟁력을 차량 관리와 고객 관리(운영 서비스)에 가진다. 더 유연한 기반에서 자동차를 제공하는 개념이 만들어졌다. 두 조직이 플랫폼– DriveNow (디지털 서비스)을 개발하기 위해 손을 잡았다. 두 파트너는 눈 높이에서 일하고 있으며 파트너십에 크게 공헌하고 있다.

• 다른 흥미로운 생태계 전투는 자동차 인포테인먼트에 관련된 순간에 일어나고 있다. 이것은 전통적으로 OEM이 통제하던 고비용, 고이윤 장비이다. 그것은 OEM이 잃기를 원하지 않는 고객에게의 직접적인 연결을 허용한다. 그것은 도전과 기회에 관한 것이다. 구글과 애플은 그들의 커넥티드 서비스로 들어가 균형을 깨뜨렸다. 조정은 만들어지고 있지만 최종적인 안정된 생태계는 아직 확립되지 않았다.

고객들은 이제 그들이 조립해야하는 빌딩 블록의 모음이 아닌 양단간 솔루션을 찾고 있다. 고객들은 개방된 표준과 상호운용성을 기대한다. 고객들은 그들의 운용상의 필요성에 맞춰 진화하는 제품과 솔루션을 요구한다. 현재 우리는 IoT 기술의 사용에 관해서는 그저 표면을 긁고 있을 뿐이다. IoT 솔루션이 더 많은 가치를 최종 소비자에게 주기 위해 수평과 수직 모두로 계속 확장될 것이 기대된다. 파트너 생태계는 고객이 증가하는 복잡한 문제를 다루가 위해 더 깊은 산업 전문 지식과 산업 어플리케이션의 우물에 접근하는 것을 제공한다.

우리는 최근 소형 산업 전동 공구(물리적 자산)을 위한 ‘디지털 운용 서비스’를 향상시키기 위한 프로젝트에서 일하면서 이 상황을 접한다. 옵션은 이것을 폐쇄적으로 유지하거나 개방 표준으로 만들어 모든 제조사의 소형 전동공구와의 통합을 허용하는 것이었다. 우리는 산업 인터넷 컨소시엄에 이것을 소형 산업 공구의 테스트베드로 만들 것을성공적으로 제안함으로서 후자를 택했고 게다가 플랫폼을 개방했다. Bosch는 전반적인 솔루션에서 최상의 경쟁력을 가져오기 위해 Tech Mahindra, Cisco, Mongo DB, Dassault Systems과 함께 생태계를 확립했다.

생태계의 중요한 부분은 알맞은 파트너를 확인하는 것이다. 그런 생태계는 하청과 맞대고 이윤을 공유하는 것에 기초했을 경우에 가장 잘 작동할 수 있다. 이것은 각 이해당사자가 생태계에 대한 자신의 기여에 다른 생각을 가지고 있기 때문에 말처럼 쉽지 않다. 생태계 파트너 간의 상호 신뢰는 매우 중요하다. 고객 수준에서 협력하는 능력(사업 세계에서 가장 두려워하는 것)은 가장 가치있는 파트너십이다. go-to-marke 협력에서 요구되는 신뢰는 막대하다. 그것이 상대의 제품과 전문시술에 대한 믿음만이 아니라두 당사자가 상대가 상호 이익을 위해 일할 것이라고 믿기 때문이다.

우리가 앞에서 논한 “두 세계의 충돌”로 돌아가자. 제조업 진영과 인터넷 진영 중 어떤 진영에 당신이 속하는 가를 확인하는 것은 중요하다. 어떻게 이것이 현실적으로 능력 인도와 시장 접근으로 번역될 수 있는가? 우리는 핵심 능력에 집중하고 생태계의 유기적 개발을 허용해야 하는가? 혹은 중요한(아마도 통제하는) 역할을 형성중인 생태계에서 목표로 해야하는가? 우리는 어디서 시작해야 하는가? 우리가:

• 정확한 역할을 정해야 하는가?

• 법적 기초나 전략적 파트너십 협약을 확립해야 하는가?

• 새로운 제품 개발에 협조해야 하는가?

• 공동 시판 활동-공식 발표, 선구자적 리더십 이벤트, 온라인 회의 등을 시작해야 하는가?

IoT는 여전히 초기 단계에 있으며, 선행 투자를 요구하고, 즉각적인 수익 (다음 사분기라던가)은 얻을 수 없지만 대신에 좋은 장기 수익의 기초를 깔 수 있다. 대부분의 부분에서, 중간 관리 (단기간 수 지향)은 이 기대상의 부조화를 관리하기가 어려움을 발견할 것이다. 더욱이, IoT 프로젝트 기간은 다양한 수직과 수평에 걸친다. 여전히 그런 계획을 선도하는데 가장 적합한 그룹에 대한 명료성의 부족이 있으며, 많은 팀과 개인은 정치운동을 시작했다. 그런 파트너십은 이들 복잡성을 다루고 방향을 제시하기 위해 C수준 (어떤 때는 보드)으로 막대한 개입과 투자를 요구한다.

조직들은 그저 “당신을 사랑해”라고 말할 뿐인 협약 더미에 사인하는데 낭비할 시간이나 돈이 충분하지 않다. 성공적인 생태계는 높은 수준의 신뢰, 알맞은 소통 방식, 상호보완적인 기능을 포함한다. 극단적인 신중함이 그런 생태계를 설립하는데 요구된다.

IoT 사업 사례 개발

사업 모델의 모든 전략적 측면을 이해하는 것이 중요하지만, 많은 최고 중역들은 양적 관점, 즉, 견고한 사업 사례에 특정한 관심을 가진다.

                           Business Case Context

사업 사례가 항상 진보적이기 때문에, 어떤 관리자들은 피고용인들이 엑셀에 기반해 작업한 성과에 냉소적인 시각을 가진다. 하지만 대부분의 관리자들은 이들 작업이 팀이 정말로 사업 모델의 상세한 부분에까지 모든 측면을 생각하도록 하는데 좋은 방법이라고 동의한다. 많은 예산 논의는 상세한 사업 사례 계산의 질뿐 아니라, 이 계산의 결과 팀이 제시한 단일 숫자에 의해서도 결정되어왔다. 이 맥락에서, 개발되고 있는 사업 사례의 범위를 이해하는 것은 특히 중요하다. 서문에 나온 자산과 IoT 솔루션간의 차이를 상기하라: 사업 사례가 완전히 자산에만 관련되는 것이든 IoT 솔루션에만 관한 것이든 이해하고 소통하는 것이 절대적으로 중요하다. 우리가 이미 많이 예시로 사용했던 eCall을 예로 들자: 당신이 eCall 서비스 만으로 얼마나 많은(혹은 적은) 돈을 벌 수 있는가에 대한 사업 사례를 계산하는 것인지 아니면 얼마나 많은(혹은) 적은 자동차를 eCall 서비스 제공(혹은 비제공)을 통해 팔 수 있을지를 계산하는 것인지를 이해하는 것이 중요하다. “지역” IoT 솔루션의 ROI는 항상 긍정적이지는 않다는 점을 명심하라. 많은 사례에서, 추가적 투자는 자산의 관점에서 “경쟁을 위한 비용”일 것이다.

IoT 솔루션의 지역 ROI에 대해 좀더 자세히 말해보자. 아래 그림은 일반적인 IoT 사업 사례 모델의 개관을 제공한다. 이 모델은 모든 IoT 솔루션이 자산 향상 (예를 들면, 자산 하드웨어)과 자산의 새로운 연결성을 개선하여 시행되는 서비스의 결합으로 구성되어 있다는 간단한 가정에 기반한다. 이 서비스는 완전히 자동화된 IT 서비스이거나, 사람이 조작하는 콜센터 같은 서비스 이거나, 둘 다일 수도 있다. 그래서 자연스럽게, 자산 향상과 서비스는 비용과 이윤 양쪽 측면 모두에 나타난다. 비용 면에서, 우리는 보통 자본 지출 (CAPEX)과 운용 지출 (CAPEX) 사이를 식별해야 한다. 반면 이윤 측면에서는 선행 투자 이익 (예를 들면, 하드웨어 판매나 서비스 가입 비용)과 순환수익 (예를 들면, 서비스 구독료)간을 식별해야 한다. 이 모든 것을 하나로 합쳐서 생각하는 것은 “지역” IoT 솔루션 ROI를 계산하는데 도움이 된다. 실제로 로켓 과학은 아니지만, 우리의 경험에서는 IoT 사업 사례를 팔 때는 그 주요 요소를 아래와 비슷한 방법으로 시각화시키는 것이 꽤 도움이 된다.

다음 시각은 아래 그림에 나와있는 전반적인 사업 사례이다. 다시, 이것은 자산 향상과 서비스 둘 다 보아야 한다. 하지만, 이 시각에서 우리는 또한 한쪽에서는 비용 절감과 작동 효율을, 다른 쪽에서는 차별화와 전략적 이익을 보아야 한다. 어떤 사례에서는, 이를 수량화하는 것이 가능할 것이다. 다른 사례에서는, 이 사례는 양적으로 논해질 수 없을 것이다. 어떤 사례든, 매우 구조적인 방법으로 전반적인 사업 사례들의 이들 다른 측면을 나타내는 것은 유용하다.

                       Overall IoT Business Case

사업 사례 과제

처음 보기에는 분명하지 않지만 IoT 사업 사례에는 물론 많은 과제가 있다. 그의 경험에 기반하여, University of St. Gallen 의Felix Wortmann은 두 중요한 IoT 사업 사례 과제를 지적한다:

“우선, IoT 하드웨어의 개발을 위한 고정 원가는 과소평가되어서는 안 된다. 이것이 전통적인 하드웨어 공동체에는 분명 새로운 것이 아님에도, 소프트웨어 배경을 가진 사람들은 종종 새로운 개발 방법론과 Arduino and Raspberry Pi 맥락에서의 최신 진보가 근본적으로 하드웨어 개발의 법칙과 경제를 바꾸었다고 생각한다. 그리고 Arduino sets이 50$ 미만으로 가능했던 사례처럼 오늘날 첫 프로토타입이 저 예산 하드웨어에서 실현될 수 있다. 하지만 그 분야에 실제로 배치될 수 있는 신뢰성 있는 하드웨어를 만드는 것은 여전히 매우 높은 관련 비용이 든다. 그것은 단순히 초기 디자인과 시제품화의 문제가 아니다. 테스트와 증명에 요구되는 투자와 IoT 능력을 실제로 통합시키는 비용 또한 고려되어야 한다. 이는 매우 초기에 첫 이윤이 생성되기 전에 발생하는 막대한 고정 원가를 고려해야 함을 의미한다. 이런 이유로 막대한 위험이 있는 것이다. 거기에 더해, 사업 모델은 종종 고정 원가에 대처하고 단위 원가를 가능하게 하기 위해 규모의 경제에 의존한다. 이런 생각들을 묘사하기 위해, 전기 자전거를 위한 보안 솔루션의 사업 사례를 예로 들어보자. 초기 가정은 센서가 자전거 외부에 간단히 부착될 수 있다는 것이었다. 하지만, 전반적인 사업 사례를 더 깊게 파고들어가자, 설득력 있는 사용 사례를 제공하고 수용 가능한 단위 원가를 성취하기 위해서는, 센서가 자전거의 전동장치 바로 안에 디자인되어야 한다는 것이 드러났다. 이는 초기 투자를 극적으로 증가시켰고 전반적인 사업 사례에 근본적으로 영향을 주었다. 둘째로, IoT가능 커넥티드 제품은 지속적으로 작동 비용을 만들어내는 백엔드 인프라를 요구한다. 이는 판매된 후에는 비용을 만들어내지 않는 비 커넥티드 제품과의 근본적인 차이이다. 그러므로, 커넥티드 제품의 작동 비용은 논의되어야 한다. 그들은 일시불 판매 가격으로 계산되거나, 진행 지불이 도입되어야 한다. 하지만, 이용 회수제나 구독 기반 모델은 보통 하드웨어가 작동하기 시작했을 때 심각한 고객 수용 문제에 직면한다. 소비자 맥락에서는 특히, 사람들은 커넥티드든 아니든 물리적 물체에 지속 지불을 하고 싶어하지 않는다. 이는 작동 비용이 판매 가격 안에 계산되어야 한다는 것을 의미한다. 위험 보험의 일종으로, 회사들은 계획적 구식화 같은 다양한 전술을 사용한다. 또한 회사들은 IoT 기반 제품이 제공자가 중앙 인프라를 중단하더라도 여전히 작동될 수 있다는 것을 보장하려고 시도한다. Philips Hue를 예로 들자: 이 커넥티드 전구는 필립스 백엔드가 없이도 로컬 게이트웨이 통제를 기반으로 작동하도록 디자인되었다. 이는 효과적으로 필립스에게 “우아한” 출구 전략을 위한 기회를 준다: 만약 고유의 백엔드 서비스를 중단한다면, 고객은 기능저하를 겪겠지만 제품은 여전히 작동한다.”

이들은 그저 IoT 사업 사례 복잡성의 몇몇 예시일 뿐이지만 개발을 위한 구조적 과정이 유용한 이유와 특정 수준의 성숙도에 도달하는데 시간이 걸리는지를 보여준다.

사업 모델과 특히 사업 사례가 미래 가치 흐름을 다루기 때문에, 그들은 불확실성에 종속된다. 의사 결정자의 투명성을 증가시키고 그런 불확실 요소들(예를 들면, 특정한 비용 추정이 매우 공허하다면, 이들 추정을 위해 다음 단계에서 제안을 요구하는 것이 도움이 될 것이다)을 다루기 위한 작업 필요성을 추론하기 위해 사업 모델의 불확실성도를 강조하는 것이 중요하다.

위험을 줄이는 유용한 도구는 시나리오 계획이다. 정해진 수치(즉, 사업 모델을 위해 추정된 타겟 그룹, 기간 등.)에 기반해, 다양한 미래 시나리오가 그려진다. 이는 트렌드나 원인-결과 관계에 기반하여 행해진다. 다음 단계에서, 계획은 어떻게 사업 모델이 가장 잘 미래 시나리오에 대응할 수 있을지를 정하기 위해 작업을 해야 한다. 전략적 맥락에서 영향과 가치를 만들어내는 사업 모델의 이런 요소들을 탐색하는 것이 중요하다. 다양한 미래 기회를 실행하기 위해, 약한 부분과 강한 요소는 밝혀져야 하며, 이는 미래에도 경쟁력이 있는 사업모델의 개발을 가능하게 할 것이다.

종합해서 만들기: 사업 계획

IoT 사업 모델 빌더에 기반할 수 있는 개발된 사업 모델을 가지면, 팀은 실행 가능한 사업 계획을 종합하여 만들 필요가 있다. 물론 이는 사업 모델의 많은 요소들을 재사용할 것이지만 계획 실행에 강하게 초점을 둘 것이다. 실리콘 밸리의 가장 존경 받는 벤처 자본 회사인 Sequoia Capital은 시작 시 다음 접근법을 추천한다 [SC1]:

• 목적: 사업을 단일, 평서문으로 정의하라

• 문제: 고객의 고통과 어떻게 오늘 대응하고 있는지를 묘사하라

• 솔루션: 당신의 솔루션이 어떻게 고객의 문제를 다루었는지를 보여주는 사용례를 제공하라. 제품의 물리적 위치를 묘사하라.

• 왜 지금: 당신의 솔루션 범주의 역사적 진화를 묘사하라. 오늘날 파괴를 가능하게 하는 요소들을 묘사하라.

• 시장 크기: 이용 가능한 전체 시장과 정확한 고객 프로필에 기반하여 당신의 솔루션이 목표로 하는 부분을 묘사하라.

• 경쟁: 주요 경쟁자를 묘사하고 경쟁우위를 비교하라

• 솔루션: 주요 지적 자산에 더해 형태 인자, 기능 요소, 구성과 개발 로드맵을 묘사하라

• 사업 모델: 이윤과 가격결정 모델, 평균적인 계좌 크기, 고객평생가치, 판매&유통 모델, 현재 고객 파이프라인의 설명(있다면)

• 팀: 새로운 사업을 위한 제안된 조직적 관리 구조

• 재정: 기되 대는(즉 3년) 이익과 손실 계획, 균형 시트와 현금 흐름 계획, 투자 요구사항 우리는 Sequoia Capital의 본래 리스트에 내부 프로젝트의 필요에 들어맞게 하기 위해 약간의 작은 변화를 가했다. 하지만 일반적으로는 “인터넷 캠프”의 지도를 따르고 내부 프로젝트 제안에 적용시키는 것이 좋아보인다. 많은 회사들은 이미 이 구조에 대조 검토되어야 할 프로젝트 제안을 위한 표준 템플릿을 가지고 있다.

다양한 IoT 투자 계획에 대해 사업 계획 발표를 들을 운영위원회에게 있어 주요 의문은: 어떻게 이들 다양한 기회들을 평가하고 우선순위를 매길 것인가? 기업 환경에서 일정량의 이면 영향력이 항상 있을 것이지만, 그것은 이상적으로 한 차트에서 여러 기회들을 계획하고 그들을 비교 가능하게 만드는데 유용할 것이다. 이 부분의 시작에서 정의된 대로, 기준평가가 전체 IoT 전략에 맞춰 조정되는 것이 중요하다.

“지역” 사업 사례 대 관련 자산의 전반적 경쟁력에 대한 IoT 솔루션의 기여에 대한 우리의 이전 논의를 감안하면, 이 두 관점을 IoT 포트폴리오 평가 차트(아래 그림의 예시)의 주요 차원으로 뽑는 것이 자연스러워 보인다. 누군가가 이 두 차원간에 적절한 균형을 잡으려 한다고 추정하면서, 그 차트는 또한 “IoT 투자 회랑”을 투자가 이상적으로 배치되어야 할 영역으로 정의한다. “정해진 시기 동안의 ROI”(혹은 경제 부가가치, EVA 같은 어떤 다른 경제 수단)가 보통 쉽게 수량화 가능한 반면, 전반적인 전략적 기여는 보통 수량화하기가 더 어렵다. 또한, 이것은 특정 자산 종류의 전반적인 가치를 회사에 포함시킬 필요가 있다. 회사 이익의 50%를 차지하는 주 자산 가치의 작은 전략적 증가는 낮은 전반적 이윤에 기여하는 틈새 자산 가치의 큰 전략적 증가를 쉽게 능가한다. 이 접근법에 포함되지 않은 다른 중요한 요소는 시장 압력, 즉, 얼마나 이 투자의 타이밍이 결정적인가다.

                         IoT opportunity evaluation chart

이들 요소의 튼튼하고 신뢰성 있는 수량화를 만들어내는 것은 항상 어렵다. 또한 정치적 파워 플레이와 기업 의사결정 과정에 수반되는 다른 요소들의 중요성을 과소평가해서는 안 된다. 하지만, 여기서 설명된 접근법은 최소한 IoT 투자 결정 과정의 일정 수준의 투명성과 객관성을 만들어내는 데에는 도움이 된다. 그리고 다시, 최종 결과는 “IoT 투자 평가 차트”라고 불리지 않을 것이고 더 수직적으로 특정한 “커넥티드 차량 기회 평가 차트” 같은 것으로 불릴 것이다. 하지만 기본 원칙은 적용할 것이다.

상세한 사업 계획과 병행하여 보통 일어나는 일은 이상적인 조직 구성과 실행 전략에 대한 평가이다. 중요한 시장 대응 시간 요소에 더해, 내부 실행 능력을 결정적으로 본다. 다시, 이는 서론의 “기계 진영” 대 “인터넷 진영” 논의로 돌아온다 – 우리는 어느 방향에서 왔는가? 그리고 우리는 어디서 끝낼 필요가 있는가? 우리는 요구되는 문화와 능력을 내부적으로 개발할 수 있는가?

Ignite | IoT 솔루션 전수는 IoT 제품 관리자, 프로젝트 관리자, 솔루션 설계자 및 기타 IoT 이해관계자를 대상으로 한 Ignite | IoT 방법론의 일부이다. 목표는 기술 독립적이며 재사용 가능한 오픈 소스 방법론의 형태로 이용 가능한 IoT 최고 사례를 만드는 것이다. 그리고 이는 프로젝트 템플릿, 체크리스트 및 솔루션 설계 청사진을 제공하여 IoT 프로젝트 설정 및 관리뿐만 아니라 IoT 솔루션 설계를 지원한다.

IoT 프로젝트의 주요 특징은 제품 설계 및 제조, 내장형 하드웨어 및 소프트웨어, 로컬 및 원격 통신, 기업 어플리케이션 개발 및 통합, 교차 영역 보안 등을 통합하는 단일 프로젝트 내에서 매우 다른 여러 분야를 결합하는 경향이 있다는 점이다.

                    Multiple dimensions of IoT project management

예를 들어, Part I에 제시된 eCall 솔루션을 살펴 보자. 자산의 관점에서, 이것은 현대 자동차의 상당히 복잡한 부품 구성표 (BOM)의 작은 부분에 불과하다. 그럼에도 불구하고 eCall 프로젝트 관리자의 관점에서, 자산 인터페이스를 관리하고 자산 구성 요소가 제대로 통합되어 있는지 확인하는 것은 중요하며, 이는 차 내에 텔레매틱스 제어 장치 (TCU)를 BOM과 제조 공정 모두에 통합시키기 위해 eCall TCU를 설치할 수 있는 알맞은 장소를 찾는 것을 의미한다. TCU와 소프트웨어는 개발 및 테스트에 필요한 매우 구체적인 기술로 기존의 내장 프로젝트를 대표한다. 필요한 모든 영역을 커버하는 이동 통신사 네트워크와 솔루션을 통합하고, 이 통신사 통합을 관리하는 것은 다른 기술을 필요로 하는, 작은 통신 프로젝트에 더 가깝다.

마지막으로, 콜센터가 착신 전화를 관리하고, 그 전화를 적절한 기술을 가진 직원에게 돌리고, 다시 PSAP (공공 안전 답변 지점)로 전송할 수 있게 하는 백엔드 소프트웨어를 구현하는 것은 전통적인 기업 소프트웨어 프로젝트를 연상시킨다. 우리가 볼 수 있듯이, eCall 프로젝트와 같은 중간 정도로 복잡한 프로젝트는 여러 기술의 조합을 필요로 한다.

현재, 이러한 유형의 여러 학문 분야에 걸친 프로젝트 관리에서 심층적 경험의 요구 수준을 충족하는 전문가의 수는 제한되어 있다. 성공적으로 텔레매틱스 및 M2M 프로젝트를 관리하고 현재 IoT 프로젝트에 대한 기술을 적용하기 시작한 전문가들이 그 예이다. 그러나, IoT가 더 광범하게 수용되도록 하기 위해서는, 더 많은 청중이 이를 경험해 볼 수 있도록 만들 필요가 있다. 이것이 Ignite | IoT 솔루션 전수의 목표이다. 우리는 IoT 프로젝트에 필요한 모든 다양한 기술과 학문을 통합하는 높은 수준의 방법론을 제공하고, 전문가의 경험과 우수 사례를 기록하기 위해 다른 분야의 전문가들과 협력하며, 이들을 방법론과 통합시키는 것을 목표로 하고 있다.

Ignite | IoT Solution Delivery

Ignite | IoT 솔루션 전수는 다음과 같이 나눌 수 있다.

• IoT 솔루션 라이프사이클: 이 관점은 IoT 솔루션의 계획, 구축 및 실행에 초점을 맞추고 있다.

• IoT 빌딩 블록: 이 관점은 IoT 프로젝트 차원, IoT 아키텍쳐 청사진, IoT 기술 프로파일 형태의 성공적인 프로젝트로부터 재사용 가능한 아티팩트를 포함하고 있다.

• IoT 프로젝트 DB: 이것은 IoT 솔루션 라이프사이클 및 빌딩 블록에 대한 모범 사례를 도출하기 위해 분석된 참고 프로젝트의 데이터베이스이다.

The IoT 솔루션 라이프사이클은 다음과 같은 구성 요소를 포함한다.

• 초기 프로젝트 설계: 이 설계 청사진은 IoT 기술 프로파일을 이용한 기술 선택, IoT 아키텍처 청사진을 이용한 솔루션 아키텍쳐, IoT 프로젝트 차원을 이용한 프로젝트 자체 평가를 포함하는 일반 IoT 빌딩 블록의 일부로 정의된 구성 요소를 기반으로 한다.

• 프로젝트 작업 흐름: 이 청사진은 일반적으로 IoT 솔루션 프로젝트에서 발견될 수 있는 최상위 작업 흐름을 정의한다. 각각의 작업 흐름에 대한 체크리스트는 작업 흐름들의 공통적인 의존성 목록과 함께 제공된다.

The IoT 빌딩 블록은 다음과 같은 구성 요소를 포함한다.

• 프로젝트 차원: 이것은 공식적 프로젝트 요건의 전조이다. 프로젝트 차원을 프로젝트 자체 평가, 프로젝트 비교, 아키텍쳐 및 기술 선택 등을 위해 사용된다

• 아키텍쳐 청사진: 기존의 아키텍처 청사진들을 기반으로 (예: 서비스 지향 아키텍처(SOA) 등), 이들은 IoT 프로젝트에 필요한 새로운 아키텍처 관점을 추가하고 필요한 다양한 아키텍처 관점을 통합하기 위한 상부 구조를 제공한다.

• 기술 프로파일: 이러한 프로파일은 일반적으로 IoT 프로젝트에 필요한 가장 중요한 기술을 식별하고 설명한다. 이는 서로 다른 기술들의 전체 IoT 아키텍처에 꼭 들어맞는 위치를 설명하기 위해 IoT 아키텍처 관점을 활용한다. 마지막으로, 기술 선택 과정을 지원하기 위해 프로젝트 차원으로의 재연결을 시도한다.

                         Organizational challenges
                         

이러한 질문에 기초하여, 운영 위원회는 각각의 IoT 기회를 관리하는 최선의 방법에 대한 결정을 내릴 수 있을 것이다. 전형적인 선택지는 내부 프로젝트, 외부 인수, 또는 자회사를 포함한다. 또한 매우 일반적인 방법은 이들의 혼합이며, 즉 큰 기업에 뿌리를 둔 사람들의 한 부분과 인수를 통해 들어온 사람들의 또 다른 부분으로 구성된 기업체를 설립하는 것이다. 또한, 제품 및 고객 기반보다는 인수 회사의 팀과 재능에 중점을 둔 회사 인수 전략을 설명하는 용어 “인수 고용”은 최근 인기를 끌고 있다.

특히 기존의 내부 조직을 활용하여 개발된 IoT 기회에 대해서는, 조직 구성에 세심한 주의를 기울여야 한다. 특히, 솔루션 팀과 기존의 자산 조직간의 인터페이스 및 관계가 필수적이다.

Bosch에는 더 많은 사례들이 있으며, “유선형” 조직들이 사업 단위 수준으로 배열되어 있다. “이미 조직 내에 아이디어들의 소속이 있다면 더욱 쉽다”고 Silke Vogel은 말한다. “이 방법으로, 아이디어 구체화 및 사업 모델 개발을 담당하는 직원들은 프로젝트를 실행 단계로 이끌 수 있다.”

IoT 최고 기관

회사가 IoT를 장기적인 변화로 볼 경우, 이 변화를 안내하고 촉진하기 위해 IoT 최고 기관 (CoE)의 설립을 고려해야 한다. CoE의 전형적인 기능 설명에 기초하여 [AE1], IoT CoE은 다음과 같다.

• 지원: IoT CoE는 IoT 컨설팅 서비스의 제공을 통해 IoT 기회를 실현하기 위해 사업 분야를 지원해야 한다. 이 서비스는 IoT 사업 사례 작성, IoT 프로젝트 설정 및 IoT 프로젝트 실행 지도를 포함할 수 있다. 이 책의 저자로서 조금 편향되어 있긴 하지만, 이러한 서비스의 하나의 가능한 기반으로 Ignite | IoT 방법론을 당연히 추천한다.

• 안내: IoT CoE는 필요한 기준, 방법론, 도구 및 지식 저장소를 정의하도록 도와야 한다. 이들 중 일부는 매우 수직적일 것이다. 그러나, 모바일 자산에 대한 원거리 통신 인프라 같은 것들을 설정하는 모범 사례와 같은 것들이 표준화 될 수 있다 (Ignite 기술 프로파일 사례를 참조).

• 공유된 훈련: 교육 및 인증, 기술 평가, 팀 빌딩, 정형화 된 역할은 IoT 기능 개발에 적용될 수 있는 모든 확립된 방법이다.

• 측정: IoT CoE은 변형 과정을 더 투명하게 하도록 돕는 IoT용 지표 및 성숙도 모델을 만들어야 한다.

• 관리: 그들은 프로젝트 간 조정 및 기타 자세한 관리 작업으로 운영 위원회를 지원해야 한다. 특히 연결된 IoT세계에는 항상 주의 깊게 관리되어야 하는 프로젝트 사이에 많은 상호 의존성이 있을 것이다.

물론, 전용 IoT CoE을 실행하는 것은 상당한 투자이며, 많은 기업들은 다른 CoE 계획으로부터 혼합된 결과를 보고한다. CoE가 방해가 아닌 부가가치 프로젝트로 보여지는 것이 중요하다. 대개 CoE 구성에 대한 두 가지 선택지로, 지정된 CoE 자원 또는 운영 팀에 포함되지만 CoE 지원에 일정 비율의 시간을 소비할 수 있는 구성원과 가상의 CoE가 있다. 후자는 많은 경험과 실무 프로젝트 배경을 가진 CoE 전문가라는 이점을 가지고 있지만, 이러한 매우 존경 받는 전문가들은 종종 프로젝트 작업에 압도당해 자신의 파트 타임 CoE 역할을 충족하지 못한다는 단점이 있다.

마지막으로, IoT 여정에 착수한 기업들은 다른 IoT 프로젝트에 의해 공유될 수 있는 IoT 플랫폼의 설치 및 운영에 투자하는 것을 고려해야 한다. 이러한 플랫폼은 다음을 포함할 수 있다.

• 원격 자산 연결, 예를 들어 통신 사업자 또는 MVNO (모바일 가상 네트워크 운영자)의 M2M 플랫폼을 기반으로 (기술 프로파일의 M2M/IoT 통신 서비스 부분 참조).

• IoT 어플리케이션 개발 및 실행 시간 (기술 프로파일의 플랫폼 및 실행 부분 참조)

• IoT 데이터 관리 인프라 (기술 프로파일의 [빅] 데이터 및 프로세스 관리 부분 참조)

• IoT 보안 인프라, 예를 들어 중앙 ID 및 인증 관리 (기술 프로파일의 보안 부분 참조)

• 표준, 예를 들어 통신 프로토콜 등

• 자산 인터페이스 저장소, 예를 들어 조직에서 중요한 역할을 하고 다른 종류의 장치 및 자산의 기능적·기술적 인터페이스를 설명하는 중앙 위키

이론적으로, 이러한 IoT 플랫폼을 제공하는 것은 프로젝트를 순조롭게 시작할 필요가 있는 모든 사람들에게 다행스러운 일로 간주되어야 한다. 그러나, 우리는 확실히 이러한 중앙 플랫폼 방식에 내재하는 위험을 인식해야 한다. 이러한 위험 중 하나는 플랫폼이 실제로 작동하지 않을 수 있다는 것이다 (지나치게 구조화되어 있으며, 현장 테스트를 거치지 않았기 때문에). 또는 시간 내에 준비되지 않을 수 있다. 아니면 비효율적이고 조작하기 너무 어려울 수도 있다.

이는 단지 중앙 플랫폼 개발과 관련된 실제 위험의 일부일 뿐이다. 반면 각각의 개별 프로젝트로 수행되어야 하는 경우, 프로젝트 팀이 절반의 시간은 제대로 맞출 수 없을 것이라는 실제 위험 또한 존재한다. 그래서 합리적인 방안은 최고의 플랫폼 방식을 개발하는 초기 프로젝트를 관찰하는 것이며, 일반화될 수 있는 이러한 프로젝트의 일부를 식별하는 것이다. 그래서 이것은 정말 성숙도 및 타이밍의 문제이다.

우리가 처음에 설명한 바와 같이, 여기에 설명된 일부 과정과 방법은 매우 포괄적이며, 수직적인 요구와 개별 조직의 특정 상황에 적용될 필요가 있다. 일부 기업의 경우, 여기에 설명된 것처럼 상세한 사업 모델을 개발하는 정교한 방법은 지나친 것처럼 보일지도 모른다. 그러나 우리는 상당한 시간과 많은 반복을 소요하는 이러한 사업 모델 개발의 많은 사례를 보았다. 특히 기존의 복잡한 대규모 생태계에 포함될 필요가 있는 솔루션의 경우가 그러하다.

프로젝트의 조직 구조에는 특별한 주의가 필요하다. IoT 프로젝트는 거의 항상 다양한 기술을 가진 다문화 팀을 필요로 한다. “인터넷 캠프”와 “기계 캠프”를 정렬하는 것은 어려운 작업이다. MongoDB, Inc.의 이사 Joe Drumgoole는 한 가지 가능한 방법에 대해 다음과 같이 설명한다. “사물의 인터넷은 상호 작용하는 두 지역 사회 모두에 체계를 제공한다. [큰 회사들]이 두 세계 사이에 다리를 만들 수 있다면 그들은 성공할 수 있지만, 나는 성공은 파트너의 수가 적은 초기 에 올 것이라 생각한다. 인터넷 구성원으로 시작해서, 그들을 제조업체 구성원을 행동하도록 자극하기 위한 포장으로 사용한다.”

고려해야 할 또 다른 중요한 것은 초기 단계의 스타트업 또는 프로젝트에 대한 사업 계획이 주요 변경 없이 첫 해를 살아남기는 거의 어렵다는 것이다. 그래서 민첩한 개발 방식 (이는 조직화되지 않거나 통제되지 않는다는 의미는 아니다)을 지원하는 것이 IoT 계획의 핵심 성공 요인이 될 것이다. 우리는 다음 부분 Ignite | IoT 솔루션 전수 방법론에서 이에 대해 더 자세히 다룰 것이다. 이 방법론은 IoT 프로젝트의 다음 단계를 지원하도록 설계되었으며, 이 프로젝트는 아이디어와 비전의 구현을 시작하기에 충분한 자금으로 전략 선택 과정을 완수하도록 관리되어왔다.

물론 IoT 솔루션의 계획, 구축 및 실행은 솔루션마다 다르다. 그러나, 우리는IoT 솔루션 사이에 공통점이 있다고 믿으며, 이는 우리가 일반적인 방법론적 접근 방식이 어떠해야 하는지에 관해서 특정 가정을 할 수 있게 한다. 우리는 구체적으로 우리의 접근 방식을 논의하기 전에 우선 이러한 가정의 일부를 설명할 것이다.

우리는 이미 이 책의 첫 부분에서 자산과 관련 백엔드 서비스 등에 초점을 맞춘 IoT 솔루션의 핵심 요소에 대한 기본 가정 중 일부를 논의했다 (서론의 “Enterprise IoT” 부분 참조). 우리가 만들고 있는 또 다른 핵심 가정은 IoT 솔루션 프로젝트가 초기 계획 단계를 포함하는 다른 프로젝트와 거의 비슷할 것이라는 점이다. 이러한 단계는 초기 출시 버전이 구축되는 단계와 솔루션이 작동, 관리, 향상되는 단계, 즉 계획/구축/실행 단계이다.

프로젝트 팀은 주어진 상황에 따라 프로젝트 관리 방법을 선택할 것이다. 프로젝트 실행이 고정 가격에 기반하여 아웃소싱 될 경우, 기회는 더 전통적인 폭포수 모형에 적용될 것이다. 이 경우, RFI (정보 요청)가 “계획” 단계의 일부로 발부되며, 법적 구속력이 있는 RFP (제안 요청)이 뒤따른다. 또 다른 팀은 예를 들어 방법론으로 SCRUM을 활용하여, 민첩한 접근법을 적용하기로 결정할지도 모른다. 이 경우, 프로젝트의 자세한 사항은 사용자 스토리에 기초하며, 이는 빠른 실행을 위한 주요 투입을 구성하고 중앙 제품 백로그에서 관리된다. 이러한 사용자 스토리는 대개 상대적으로 상세하며 이상적으로 필요에 따라 생성된다. 그러나, 대부분의 민첩한 접근법은 또한 기능적, 구조적 관점에서 전체적인 솔루션을 설명하는 더 높은 수준의 설명서를 사용한다. 그래서, 어떤 의미에서, 민첩한 프로젝트는 “계획” 단계 (때로는 “스프린트 제로”로 알려진)를 포함한다. 선택된 민첩한 접근법의 종류에 따라, 프로젝트의 “구축” 및 “실행” 단계는 달라질 수 있다. 예를 들어, 일부 민첩한 프로젝트는 주요 발표에 집중하고 긴 테스트 단계를 포함하는 전통적인 접근법에 가깝다. 또한 이는 때때로 폭포수 모형(waterfall)과 민첩함(agile)의 조합인 “wagile”방식이라고 불린다. 다른 민첩한 프로젝트들은 빠른 결과가 지속적으로 배열되는 접근법을 매우 신중하게 채택하려고 시도한다.

프로젝트 관리에의 또 다른 일반적인 접근법은 V-Model이다. 예를 들어 이것은 중부 유럽의 정부 운영 프로젝트에서 일반적으로 사용된다. PRINCE 2에서 합리적 통합 프로세스 (RUP)까지 다른 많은 접근법이 있다. 그러나, 우리는 보통 일반적인 계획/구축/실행의 관점이 서로 다른 접근법 모두에 적용될 수 있다고 말하는 것이 타당하다고 믿는다.

                        Ignite and different project approaches
                        

프로젝트 관리를 위해 이러한 서로 다른 접근법을 모두 지원해야 할 필요성을 감안할 때, 다음 Ignite 방법론은 IoT 솔루션에 특화된 것에 초점을 맞추며, 프로젝트 관리자가 프로젝트 관리 모델을 선택해 솔루션과 결합시킬 수 있도록 한다.

프로젝트 구조의 측면에서, Ignite 접근법은 아래 그림에서 보여지는 높은 수준의 구조를 기반으로 한다. 첫 번째로 우리가 볼 수 있는 것은 자산 자체와 IoT 프로젝트 사이에 차이가 있다는 점이다. 자산의 설계 및 제조는 IoT 솔루션 프로젝트의 범위 내에서 일반적이지 않다. 그러나, 자산과 IoT 솔루션 프로젝트에 대한 책임이 있는 조직 간의 인터페이스를 인식하는 것은 필수적이다. 하나 이상의 IoT 솔루션을 지원하도록 자산이 처음부터 설계되는 상황뿐만 아니라, IoT 솔루션이 자산의 초기 설계 (“개조”) 이후 자산과 통합되는 상황에서도 이는 적용된다. 어느 경우에도, IoT 솔루션은 솔루션의 백엔드 서비스 인터페이스를 정의하는 특정 “자산 상의” 하드웨어 및 소프트웨어에 의존할 가능성이 높다.

Ignite project structure

Ignite | IoT 솔루션 전수의 또 다른 핵심 요소는 전형적인 프로젝트가 착수 단계와 주요 실행 단계를 가지고 있다는 가정이다. 사업 사례가 승인되고 조직이 원칙적으로 프로젝트를 진행하라는 명령을 내리면 착수 단계는 시작된다. 이 단계에서, 즉 자원의 증가 이전에, 보통 상대적으로 작은 팀이 프로젝트에 참여한다.

다음은 주요 실행 단계이다. 이 단계에서의 Ignite 접근법은 우리가 “작업 흐름”이라고 부르는 개념을 기반으로 한다. 이는 주요 프로젝트에 걸쳐 적용되는 최고 수준의 구조이다. PMI의 측면에서, 작업 흐름은 작업 분류 체계 (WBS)의 최상위 작업 항목이 될 것이다. 우리의 경험에서, 용어 “작업 흐름”은 다른 모든 이해 관계자 및 종속성과 함께 IoT 프로젝트 관리의 매우 역동적인 특성을 더 잘 반영한다.

Ignite | IoT 프로젝트 착수 단계의 중요한 측면은 요건 분석이며, 이는 사업 모델 생성 단계에서 수행된 분석보다 더 면밀하다. 비교하자면, 요건 분석은 초기 솔루션 설계를 지원할 수 있는 수준의 세부 사항에 도달하기 위한 목적으로, 특정 사용자 요건을 깊게 살펴 본다. 프로젝트 착수는 일반적으로 각 분야의 전문가로 이루어진 작은 팀에 의해 수행된다. 특히, 팀은 전용 솔루션 설계를 가지고 있어야 한다 (사업 모델 생성 단계에 깊이 관여되지 않았을 수 있다). 또한, 팀은 광범위한 영역의 지식과 솔루션의 기능적인 측면에 대한 명확한 비전을 가진 사업 분석가를 포함해야 한다.

우리가 “두 세계의 충돌”에 대한 이전 논의를 기억한다면, 적합한 사업 분석가 및 솔루션 설계자를 찾는 것이 중대하지만 어렵다는 것을 알 것이다. 예를 들어, 사업 분석가가 일반적으로 자산에 대한 책임이 있는 사업 부문에서 올 경우, 서비스 관점에서 생각하기 어려울 지도 모른다. 반면, 서비스 중심의 사람이 이 역할에 선택될 경우, 그들은 자산 영역에서의 오랜 경험으로부터 비롯된 심층적인 영역 지식이 부족할지도 모른다. 어떤 경우에는, 따라서 상호보완적 배경을 가진 여러 전문가를 선택하여 IoT 프로젝트 착수 단계 팀을 구성하는 것이 유용할 수 있다.

프로젝트 착수 팀은 이 단계에서 이해 관계자 분석, 환경 분석, 요건 분석, 위험 및 자원 평가 등 일반적인 많은 작업을 수행해야 한다. 다음에서, 우리는 어떠한 추가적인 IoT 고유의 측면이 이러한 표준 프로젝트 작업에 추가될지에 대해 설명할 것이다. Ignite | IoT 프로젝트 착수 단계의 최종 결과는 이전에 설명된 작업 흐름 구조를 기반으로 한 초기 솔루션 설계 및 프로젝트 구조이다.

                               Project initiation
                               

Ignite | IoT 솔루션 전수는 아래 그림에 표시된 초기 솔루션 설계를 위한 주요 아티팩트를 정의한다. 우리는 분석, 예측, 계획, 기능 설계 아티팩트 및 기술 설계 아티팩트를 포함하는 아티팩트들의 차이를 논한다. 그들은 병렬로 생성될 수 있지만, 이 부분에 기술된 바와 같이, 종종 그룹화하는 것이 합리적이다.

Ignite | IoT 솔루션 전수가 제안하는 일부 아티팩트, 예를 들어 이정표 계획은 항상 IoT에 특화된 것은 아니다. 일부 아티팩트는 IoT 솔루션을 위한 제안된 수량 구조 또는 SOA 랜드스케이프 등 IoT에 특화된 확장자를 가지고 있다. 그리고 일부 아티팩트는 IoT 프로젝트 차원, IoT 솔루션 스케치, 또는 자산 통합 아키텍처 등 IoT 솔루션 설계를 위해 특별히 만들어졌다. 책의 이 부분에서는 우리는 어떻게 프로젝트 팀이 설계 단계에서 이러한 아티팩트로 작업할 수 있는지에 더 집중할 것이다. 이러한 이유로, 우리는 여기에서 사례를 먼저 제공하고, 다음 “빌딩 블록” 부분에서 더 공식적인 정의를 제공할 것이다.

전문화된 설계 아티팩트는 소프트웨어 설계에서 긴 이력을 가지고 있다. 특히, 합리적인 통합 프로세스 (RUP)는 소프트웨어 프로젝트의 서로 다른 관점과 단계에 대한 전문 소프트웨어 설계 아티팩트의 완전한 집합을 기반으로 한다. RUP는 과거에 너무 많은 아티팩트를 기반으로 하여 일부 비판을 받았다. SCRUM같은 민첩한 접근법은 종종 아키텍쳐 아티팩트보다는 사용자 스토리 같은 아주 기본적인 아티팩트에 의존하고 있다. 민첩한 관점에서 “코드는 진리이다”. Ignite | IoT 솔루션 전수는 두 극단 사이에서 균형을 유지하려고 한다. 우리의 경험에 의하면, 이는 특정 표준화된 아키텍처와 설계 아티팩트에 의존하는 데 매우 도움이 될 수 있으며, 다른 프로젝트 이해관계자들이 이해를 같이하도록 보장한다. 이를 위해, Ignite | IoT 솔루션 전수는 아티팩트가 충분히 가벼우면서도 충분히 표현 가능하다는 것과 다른 유형의 아티팩트들이 중복을 최소화하면서 서로 잘 통합된다는 것을 보장해야 한다.

                            Initial IoT Solution Design

첫 번째 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 /생산 시작 (하드웨어)

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

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

이 단계에서 Ignite | IoT 방법론에 의해 제안된 기능 설계의 세부 사항 수준은 RFP (제안 요청)에의 가벼운 응답에서 찾을 수 있는 것의 전형이다. 이는 특히 세부 요구 사항을 수집하고 관리하기 위해 준비된 제품 백로그로의 민첩한 접근법을 사용할 경우, 프로젝트 실행 단계를 시작하기에 충분해야 한다. 여기에 설명된 기능 설계는, 예를 들면 고정 가격 제안의 상세 요건을 충족하도록 의도된 것은 아니다.

기능 설계를 만들기 위한 좋은 첫 단계는 가장 중요한 사용 사례에 대한 높은 수준의 분류를 정립하는 것이다 (엄밀히 말하자면, 초기 사용 사례 분류가 원래 분석의 일부로서 만들어져야 하지만 이것이 중요 설계 아티팩트이기 때문에 우리는 이것을 여기에 포함시킨다). IoT 솔루션의 경우, 이러한 사용 사례는 종종 자산 라이프사이클을 좀 더 자세히 봄으로써 식별될 수 있다 (서론의 연결된 자산 라이프사이클 관리에 대한 설명 참조). 각 사용 사례 정의는 정립된 사용 사례 설계에 대한 모범 사례를 따라야 하며 (참조 추후결정), 관련된 이해관계자/역할과 활동에 대한 높은 수준의 설명을 제공한다.

대안적으로, 더 과정 지향적인 조직에서는 과정 중심 접근법이 사용될 수 있다. 이 경우 사용 사례 분류 대신에, 솔루션에 대한 과정 가치 사슬이 (다시, 아마도 자산 라이프사이클을 기반으로) 만들어질 수 있다. 선택된 과정의 경우, 예를 들면 ePC 또는 BPMN를 사용하여 과정 흐름도를 이용하는 것도 가능하다. 그러나 이 경우, 우리는 “행복 경로” 과정 흐름에 중점을 둔 상당히 높은 수준을 고수할 것을 권장한다.

취한 접근법에 관계없이, 이 작품은 일반적으로 솔루션 설계자의 지원으로 팀의 사업 분석가에 의해 수행된다. 많은 사업 분석가 및 솔루션 설계자는 그들의 생각을 고도로 구조화하며, 구조화 된 접근법을 사용하여 기능 설계 과정을 시작하고자 한다. 그러나 기능 설계의 핵심은 최종 사용자 및 사업 이해관계자들과의 긴밀한 상호 작용이다. 그리고 이 집단 내에서, 우리는 종종 생각이 덜 구조화된 사람들을 찾을 수 있다. 종종 이 사람들은 추상적인 생각을 좋아하지 않으며, 예를 들어 UI 모형에 의해 제공되는 간단한 시각화를 선호한다. 이 집단의 많은 사람들이 어플리케이션 관점에서 생각하기 때문에, 이러한 관점에서 그들에게 말함으로써 효과적인 의사소통을 보장하는 것이 중요하다.

이것이 Ignite | IoT가 솔루션의 주요 사용자 인터페이스 (UI)와 인간 기계 인터페이스 (HMI)에 대한 초기 모형 생성을 권장하는 이유이다. 이 모형은 가벼우면서도 위에서 언급한 사용 사례 또는 가치 사슬 분석의 일환으로 확인된 주요 인터페이스에 초점을 맞추어야 한다. 모형은 아이디어 토론과 최종 사용자 및 사업 이해관계자의 요건 검증을 위한 이상적인 기반을 제공한다. 그들은 또한 중요한 데이터 엔티티, 사용 사례, 과정, 사건 등의 관점에서 전체 그림을 식별하고 포착할 수 있다. IoT 솔루션의 경우, 다음과 같은 모형은 일반적으로 다음과 연관된다.

• HMI: 자산 사용자 및 자산 관리자 인터페이스 (예를 들어 기계 HMI 디스플레이, 원격 웹 인터페이스, 자동차 내장 디스플레이 등)

• 최종 사용자 셀프 서비스 인터페이스: 사용자 계정 관리, 개인 사용 통계 등

• 과정 지원 인터페이스: 예를 들어 콜센터 직원을 위한 UI

• 파트너 인터페이스: 솔루션 파트너를 위한 UI, 외부 지원 제공을 위한 사건 관리

아마 위에서 설명한 모형 접근법은 매우 초기 단계에서는 구성되지는 않을 것이다. 이는 사용자 관점에 매우 중점을 두며 과정, 알고리즘, 블랙 박스 관점 같은 것을 본다. 이 때문에 Ignite | IoT 는 더 구조화되고 IoT에 특화된 설계 방식을 취하는 것을 권장한다 (다시, 분석 및 설계의 경계는 흑과 백이 아니다).

대부분의 IoT 프로젝트는 사업 모델의 핵심적인 부분이 되는 특정 이론을 발전시킨다. 예를 들어, CERN의 직원들은 아인슈타인까지 거슬러 올라가는 물리적 이론을 기반으로 대형 강입자 충돌기 (LHC)를 구축한다. 또는 구글과 Nest의 경우, 구글이 스마트 홈 기술 제공자 Nest의 인수를 통해 얻은 데이터 실행 가능 분석의 종류에 대한 가정을 했을 것이다.

이러한 이론의 한 가지 문제점은 입증될 때까지 아무도 확실히 알지 못한다는 것이다. 그리고 특히 사람들이 센서 데이터/빅 데이터에 의해 움직이는 IoT 세계에서 많은 이론과 사업 모델 가정은 수집한 데이터에서 학습함에 따라 시간이 지나면서 발전한다.

많은 IoT 프로젝트의 경우, 센서 데이터에 기반한 실제 세계의 디지털 모델 생성은 검증될 이론 및 가정의 기초가 된다. 디지털 모델의 신중한 설계 과정이 솔루션 설계 과정의 핵심인 이유이다. 사업 모델에서 만들어진 가정은 디지털 모델의 단위를 이끌어내야 할 것이다. 또한 다음과 같은 중요한 질문들에 대답할 수 있어야 한다.

• 어떤 데이터 엔티티를 수집해야 하는가?

• 얼마나 자주?

• 어떤 수준의 정확도로?

축구 게임의 예를 들자면, 비지니스 모델의 관점에서 우리는 충분한 각 게임의 결과를 수집하는 도박 기관이다. 누가 그리고 언제 골을 넣었는가와 같은 각각의 골에 대한 정보를 필요로 하지는 않는다. 우리가 축구 팀의 코치인 경우, 우리의 사업 모델은 우리가 지속적으로 팀 성과를 최적화 할 것을 요구한다. 그래서 이 경우 우리의 디지털 모델은 게임의 지속 기간 동안 각 선수의 위치를 추적하는 열지도에 가까운 것이다. 몇몇 팀은 이미 개별 선수의 성과 향상을 가능하게 하는 고정밀 위치 시스템 및 모션 캡쳐 기술을 이용하여 개별 선수의 상세한 움직임을 추적하기 시작했다. 3D로 시각화 할 때, 이 모델은 실제 게임과 매우 유사하게 보인다.

보다 상세한 디지털 모델의 생성이 프로젝트 실행, 데이터 전송 및 운영 비용을 극적으로 증가시킬 수 있음을 유의해야 한다. 당신은 많은 사례에서 어떻게 매우 간단한 디지털 모델이 강력한 사업 모델을 만들 수 있는가에 놀라게 될 것이다.

설계 과정의 다음 질문은 데이터를 수집하는데 사용될 수 있는 시작 지점에 관한 것으로, 어떤 종류의 센서를 사용할 수 있는가? 그들은 어디에 위치될 수 있는가? 어떻게 원격으로 접근될 수 있는가? 충분한 전원 공급을 보장하는 가장 좋은 방법은 무엇인가? 등이다. 이를 간단한 축구 예시에 적용해 보면 다음과 같다. 어떻게 당신은 실제로 골이 득점했다는 사실을 포착할 수 있는가? 최근까지, 축구 리그들은 골 라인 기술을 거의 허용하거나 필요로 하지 않았다. 따라서 필요한 정보를 수집하는 직접적인 방법이 없는 경우, 당신의 선택지는 무엇인가? 당신은 큰 소리의 박수 또는 항의가 골을 나타낸다고 가정하고, 박수를 측정하기 위해 축구 경기장에 마이크 시스템을 배치할 수 있겠는가?

이는 다음 단계인 “복원” 단계로 연결된다. 우리는 센서로부터 수집된 데이터가 필요한 디지털 모델에 반드시 직접 매핑하지는 않는다는 것을 볼 수 있다. 이 경우, 우리는 이용 가능한 센서 판독 및 사건 등을 가져오는 과정을 수행하고, 사업 모델을 지원하기 위해 필요한 디지털 모델을 만드는데 이 데이터를 이용한다.

명백히 인위적인 예를 들자면, 위의 간단한 축구 시나리오의 복원 과정은 실제로 골을 득점할 팀을 결정하기 위해 홈에서 경기하는 팀에 대한 정보와 큰 소리의 박수 또는 항의에 대한 정보를 결합할 수 있다.

복원 과정의 보다 현실적인 예로, 위치 기반 쇼핑 추천을 위해 소매 상점에서 고객의 움직임을 추적하도록 표지를 사용하는 IoT 솔루션을 살펴 보자. 이 예에서, 복원 과정의 첫 번째 부분은 고객의 실제 3D 좌표에 특정 표지 정보 (거리, 표지의 위치 등)를 매핑하는 것이다. 다음 단계는 추천 엔진이 작업을 수행 할 수 있도록, 잠재적 관심 영역에 고객의 위치를 매핑하는 것이다.

이 복원의 극단적인 개념을 보여주고, 실제 이 개념의 사용하도록 했던 한 가지 예는 Part I에 설명 된 CERN/LHCb 사례 연구이다.

• LHCb는 낮은 수준의 아날로그 데이터를 얻기 위해 백만 개 이상의 센서를 배치한다

• 고도로 복잡한 여러 단계의 복원 과정이 이러한 아날로그 사건을 각 개별 센서의 3D 좌표와 결합하여 각 입자의 충돌을 유도한다

• 결과는 충돌 후 각 개별 입자 궤도의 3 차원 모형이다

• 충돌의 디지털 모델을 기반으로, 물리학자들은 입자 충돌에 대한 물리학 이론을 검증할 수 있다

이 예는 복원 개념이 IoT 세계에서 얼마나 중요한지 보여준다 (당신이 이것을 올바로 할 수 있을 경우, 분명히 노벨상을 받을 수 있다). 특히 더 복잡한 디지털 모델 및 센서 데이터에 의존하는 IoT 솔루션의 경우, Ignite | IoT 방법론은 디지털 모델과 해당 복원 과정을 정의하는데 충분한 시간과 자원을 투자할 것을 권장한다.

                      Structured IoT analysis and design approach
                      

솔루션 설계자가 디지털 모델 설계 및 복원 과정 사이에 좋은 조합이 있다는 것을 확신할 경우, 이들은 설계 과정의 다음 단계에서 추상적 개념으로 이 디지털 모델을 사용할 수 있다. 우리가 보는 바와 같이, IoT 솔루션의 디지털 모델은 여러 측면을 지닐 수 있다. 그 핵심에서, 우리는 사업 데이터 중심의 기술 독립적 통합 형태을 제공하는 영역 모형 (아래 참조)을 만들 것을 권장한다. 시간이 지남에 따라, 이 모형은 사건, 구성 요소, 과정 등을 포함하도록 갱신될 필요가 있을 것이다. 영역 모형부터 시작해 보자.

영역 모형

영역 모형은 새롭지도 않으며 IoT에 특화된 것도 아니다. 그러나, 이 모형은 IoT 솔루션 핵심 데이터 엔티티에 대한 사업 중심의 통합된 관점을 만드는 데 강력한 도구가 될 수 있다. 우리는 영역 모형에 매우 기본적인 UML 요소를 사용할 것을 권장한다.

• 등급

• 속성

• 제휴

• 집단

• 상속/전문화

IoT 솔루션의 핵심 개체를 식별하기 위한 좋은 출발점은 앞에서 설명한 이해관계자 분석의 4 가지 핵심 요소이다.

• 자산 및 장치: 하나의 개체와 다섯 가지 핵심 개체를 동일시한다. 자산 및 장치의 어떤 속성이 특히 중요한가?

• 최종 사용자: 사용자 및 자산 소유자, 백 오피스 직원 등의 전문화

• 기업: 예를 들어 자산과 사용자 사이의 관계를 정의하는 핵심 개체로서의 “리스”

• 파트너: 예를 들어, 사건의 할당,

넓은 차원에서, 영역 모형은 핵심 개체와 가장 중요한 관계에 초점을 맞추어야 한다. 무엇을 생략할지 아는 것은 때때로 핵심 개체를 식별하는 것만큼 까다로운 일이 될 수 있다. 이에 대한 조언은 다음과 같다.

• “1980년대 개체/관계의 바탕 화면”을 피해라 – 영역 모형은 일반적으로 15 ~ 30 개 사이의 개체를 갖는다

• 위에 설명한 바와 같이 간단한 UML을 사용해라

• 일정 수준의 “모호함” 허용: 이 NoSQL 데이터베이스 시대와 모든 유형의 데이터를 사전에 알 수 없는 IoT 같은 환경에서 특히 중요하다

우리가 볼 수 있는 바와 같이, 영역 모형의 주요 이점 중 하나는 다른 솔루션 단계들에 걸쳐 분포된 데이터의 시각적 표현을 생성하는 기능이다. SOA (서비스 지향 아키텍처)를 활용하여, 우리는 영역 모형에서 다른 구성 요소까지의 개체를 매핑할 수 있다.

IoT domain model

자산 통합 아키텍쳐 (AIA)

자산 통합 아키텍쳐 (AIA)는 명백하게 IoT 솔루션을 위해 개발된 설계 접근법이다. 높은 수준의 개념 설명은 서론에서 이미 제공되었다. 두 가지 주요 단계인 자산과 기업은 여기서 소개된다. 이 두 단계는 IoT 클라우드 (또는 M2M 플랫폼)을 통해 통합된다. 자산에서, 로컬 게이트웨이와 에이전트 소프트웨어는 자산의 일부를 구성하는 다른 장치들과의 통합을 허용한다. 게이트웨이는 또한 백엔드와의 연결을 보장한다. 백엔드에서, IoT 클라우드는 일반적으로 시스템에 등록된 모든 자산에 대한 정보를 포함하는 통합 데이터베이스를 가진다. IoT 클라우드는 이 정보가 자산으로부터의 실제 데이터와 동기화되는 것을 보장한다. IoT 클라우드 백엔드는 일반적으로 자산 및 장치에 특화된 데이터와 기능을 포함하며, 추가 사업 서비스를 제공하는 백엔드 어플리케이션과 통합되어 있다.

                           AIA example: eCall service
                             

위의 예는 eCall 서비스의 AIA를 보여준다. eCall 솔루션은 백엔드에 있는 콜 센터 어플리케이션으로 구성되어 있으며, 이는 소위 PSAP (공공 안전 응답 지점)와 통합된다. 백엔드는 또한 eCall 사건 처리 하위 시스템을 포함하고 있으며, 이는 잠재적인 충돌 상황에 있는 차량으로부터 사건을 수신한다. 이러한 사건들은 차내 TCU (텔레매틱스 제어 장치)에서 전송된다. TCU의 주요 목적은 게이트웨이로서 작용하는 것이지만, 또한 로컬로 실행되는 일부 제한된 비지니스 로직뿐만 아니라 솔루션의 일부를 형성하는 가속도 센서를 갖는다. 또한, TCU는 CAN 버스를 통해 에어백과 통합된다.

AIA의 주요 목적은 표준화된 방식으로 IoT 솔루션의 상이한 설계 요소를 제시하고, IoT 솔루션에 다른 설계 요소의 분배에 대한 정보를 제공하는데 사용될 수 있는 캔버스를 제공하는 것이다.

데이터 분배 Data Distribution

이제 우리는 영역 모형 및 자산 통합 아키텍처의 개념에 친숙해졌기 때문에, 우리는 데이터 분배를 다루기 위해 이 두 개념을 결합할 수 있다. 이는 모든 IoT 솔루션의 매우 중요한 측면이다. 순 데이터 분배 설계는 중요한 성능 문제와 불필요한 통신 비용을 초래할 수 있다.

영역 모형에서 확인된 각각의 개체에 대해, 이 작업은 개체들이 AIA어디에 존재하는지 확인하는 것이며, 이는 설계 (그린 필드)에 의해, 또는 그들이 이미 했기 때문에 (브라운 필드) 일어난다. 데이터 분배와 밀접한 관련된 것은 주요 비지니스 규칙의 분배이다.

AIA and data distribution

숙련된 솔루션 설계자는 일반적으로 데이터 및 비지니스 규칙 분배에 적용되는 주요 제약에 대한 훌룽한 개관을 가지며, AIA의 다른 단계들 간 대기 시간 및 대역폭, 로컬 스토리지 제한, 처리 제한 등이 있다. 이러한 제약들과 원본 분석으로부터의 수량 구조 정보 (예를 들어, 예상 자산의 수 등)를 결합함으로써, 데이터 개체와 AIA 규칙을 맵핑하여 데이터 분배 설계를 위한 초기 제안을 만들 수 있다.

예를 들어, 스마트 홈 솔루션이 실온 및 기상 예보에 기초하여 결정하는 중요한 비지니스 규칙을 필요로 한다고 하자. 이 경우, 솔루션 설계자에게는 두 가지 선택지가 있다.

• A (로컬 규칙): 정기적으로 스마트 가전기기에 일기 예보 데이터를 푸쉬하고 로컬 규칙을 실행

• B (백엔드 규칙): 결정이 필요할 때마다 백엔드로 현재 실온 데이터를 보내고 백엔드에서 규칙을 실행

‘옵션 A가 백엔드에서 가전기기로 일기 예보를 푸쉬하는 것의 결과로 얼마나 많은 데이터 트래픽을 발생시킬 것인가?’ 대 ‘옵션 B 가 가전기기에서 백엔드로 데이터를 푸쉬하는 것의 결과로 얼마나 많은 트래픽을 발생시킬 것인가?’로 상충관계가 분명하다. 고려해야 할 많은 요인으로 가전 제품의 수, 필요한 업데이트 빈도 및 날씨 예보를 위한 데이터 크기, 가전 기기당 평균 규칙 실행 횟수 등이 있다.

상대적으로 간단한 예제와 그 결과로 초래되는 복잡한 분석은 데이터 및 사업 규칙에 대한 효율적인 분배 설계가 IoT 솔루션의 성공에 중요한 이유를 명확하게 보여준다.

SOA 랜드스케이프

위의 논의와 밀접하게 연관되는 것은 소프트웨어 컴포넌트화라는 주제이다. 한번 과장해보자면, 서비스 지향 아키텍처 (SOA)는 긴 학습 곡선을 지나와, 지금은 많은 사람들에게 분배된 상이한 소프트웨어 시스템과 연관된 문제를 해결하기 위한 매력적이지는 않지만 필요한 접근법으로 보여진다.

SOA는 전형적으로 두 가지 관점, 기술 프로토콜 관점 (REST 대 Web Services)과 기능적 관점을 지닌다. IoT 기술 프로토콜 표준화의 전체 영역은 여전히 매우 역동적이기 때문에, 우리는 여기에서 후자인 기능적 관점에 초점을 맞출 것이다. (추후결정: 기업 SOA 및 기업 BPM 참조)에서 설명한 바와 같이, 기능적 관점은 UI, 프로세스 로직, 결합, 기본/데이터 중심 서비스 등의 기반 기술로부터 독립적으로 어플리케이션 사일로에 걸쳐 적용될 수 있는 SOA의 4 핵심 단계를 정의한다. SOA 관점을 통해 이질적인 어플리케이션 현황을 보는 것의 이점은 어떤 어플리케이션 사일로가 어떤 데이터와 어떤 과정을 소유하고 있는지 신속히 투명화한다는 점이다.

이것은 일반적으로 얻기 어려운 중요한 정보이다. 또한, 이 관점은 비기술적 수준에서의 소프트웨어 구성 요소 및 종속성을 확인하는데 도움이 된다. 이는 예를 들어 위의 데이터 및 논리 분배 논의에 흥미 요소가 될 수 있다. 설계 과정의 나중 단계에서는 핵심 소프트웨어 구성 요소 및 인터페이스에 대한 기술 독립적 문서화의 제공도 중요해진다. 많은 경우, 위키 기반 접근 방식은 연관된 오버헤드 때문에 기술적 SOA 저장소보다 선호된다.

네트워크 대기 시간 및 대역폭 제한을 가진 분산 시스템에서 구성 요소 인터페이스 설계는 최대한 효율적이어야 한다. 분산 객체 컴퓨팅 (CORBA, DCOM, J2EE)으로부터의 경험은 복잡한 객체의 상호 작용 패턴이 대부분의 분산 시스템에 적합하지 않다는 것을 보여준다. 대신, 더 간단하고 편안한 서비스가 도입되었다. 아무것도 더 적용하지 않을 경우, 높은 대기 시간, 네트워크 서비스 중단 및 기타 문제 등의 측면들이 IoT의 개방성 때문에 하나의 요인 이상이 된다는 것을 고려하면, 같은 패턴과 제약은 IoT 소프트웨어 구성 요소 설계에도 적용된다.

따라서 Ignite | IoT는 SOA 아키텍처 설계에 대한 기존 모범 사례를 기반으로 하여 이를 IoT로 확장 할 것을 제안한다. SOA 관점에서, 자산에서 실행되는 어플리케이션은 어떤 다른 어플리케이션과도 다르지 않다. SOA는 기술 독립적 관점을 취하고 있기 때문에, 이미 이질적인 Java, COBOL 및 PL/1 코드의 SOA의 세계에 내장형 어플리케이션과 실시간 운영 체제를 추가하는 것은 아무런 영향이 없어야 한다. 아래 그림에서 알 수 있는 바와 같이, Ignite | IoT 는 오른쪽에 자산 부분을 추가하고 HMI (인간 기계 상호작용)를 포함하도록 UI 레이어를 확장함으로써, 익숙한 SOA 맵 도면으로 확장할 것을 제안한다 (추후결정: 기업 SOA 및 기업 BPM 참조).

이러한 유형의 SOA 맵은 IoT 솔루션의 일부로서 통합 또는 개발될 필요가 있는 주요 소프트웨어 구성 요소를 식별하는 것을 도와주어 매우 중요하다. SOA 관점은 SOA의 주된 초점이 주요 소프트웨어 구성 요소 및 그들의 주요 사업 기능을 투명하게 한다는 점에서 위에서 설명된 자산 통합 아키텍처 (AIA)의 관점과는 다르다. 여기에 제시된 SOA 관점은 기술 독립적이며, 사업 기능에 초점을 맞춘다. 반면 AIA는 더 시스템적인 관점을 취하며, 사용된 구체적인 기술에 대한 참조를 가능한 한 포함한다.

SOA landscape

마지막으로, 기술 설계는 솔루션의 소프트웨어 아키텍처, 하드웨어 설계 및 기술 인프라의 개요를 제공한다.

소프트웨어 아키텍쳐는 핵심 소프트웨어 구성 요소와 이들의 종속성을 정의해야 한다.

• 자산 상 OS/펌웨어, 어플리케이션 컨테이너, 미들웨어

• 백엔드 OS, 어플리케이션 컨테이너, 미들웨어 (전자 통신, BPM, BRM 등)

• 데이터베이스 기술 및 라이브러리

• ID 관리, 보안 기술, 인증서 관리 등

• 중요 소프트웨어 라이브러리 및 오픈 소스 구성 요소

• 자산 소프트웨어 업데이트 인프라

• 개발 도구

하드웨어 설계는 IoT 솔루션에 특화된 이러한 구성 요소, 보통 자산 상 하드웨어에 중점을 두어야 한다. 이 단계에서 일반적인 수준의 세부 사항은 다음을 포함해야 한다.

• 다음과 같은 요소로 구성된 게이트웨이 등의 자산 상 하드웨어: CPU, 메모리, 로컬 인터페이스, 셀룰러 모뎀, 지역 무선 연결, 안테나, 케이스, 분포된 센서 노드 등

• 자산에 위치 및 장착

• 분포된 센서 노드를 배치할 경우, 자산에 이러한 노드를 위치 및 장착

Hardware design

맞춤형 하드웨어 개발의 경우, 다음 수준의 하드웨어 설계 세부 사항은 주요 구성 요소, 즉 CPU, 메모리, 전원, 디지털 I/O, 통신 모듈 등을 다룬다. 아래 도표는 서론에서 기술된 바와 같이 eCall 서비스 텔레매틱스 장치의 메인 보드 설계 예시를 보여준다.

                   Detailed hardware design (source: peiker group)
                   

기술 인프라의 설계는 개별 솔루션, 특히 사용된 네트워크 인프라에 고도로 특화될 것이다. Alcatel-Lucent의 예는 아래 그림에서 볼 수 있다 (참조 추후결정).

                               Technical infrastructure
                               

Stefan Schuster와 Julian Bartholomeyczik는 모두 Bosch Connected Devices and Solutions (BCDS)에서 일한다. BCDS는 혁신적인 연결 장치와 IoT 맞춤형 솔루션을 개발하고 판매하는 Bosch의 사업부이다. 다음의 설명은 IoT 센서 네트워크에 대한 솔루션 스케치 작성의 예시를 제공한다.

Dirk Slama: IoT 센서 네트워크에 대한 샘플 솔루션 스케치에 대해 우리에게 설명해주실 수 있을까요?

Stefan Schuster and Julian Bartholomeyczik: 물론이죠. 솔루션 스케치는 문제 공간 (프로젝트 작업 집합)과 솔루션 공간 (이 작업을 해결하는 기술 솔루션) 모두를 포함합니다. 솔루션 스케치를 작성하기 위한 두 가지 접근 방법으로, 하향식과 상향식 방법이 있습니다.

용어와 일반적인 접근 방법에 대해 간단히 살펴 봅시다. 예를 들어 우리는 어떻게 초기 단계에서 기계의 마모를 확인할 수 있는가? 와 같은 질문의 형태로 작업이 정해져 있는 경우, 하향식 절차라고 말합니다. 이 작업을 완수하는 기술 솔루션이 만들어지며, 구성 요소들은 그에 맞춰 설계되고 만들어 집니다.

상향식 절차에서 기술 솔루션의 구성 요소는 예를 들어 기존의 플랫폼, 센서, 또는 알고리즘의 형태로 이미 존재하고 있습니다. 이 프로젝트는 사실상 탐험입니다. 이 경우 전형적인 미결 문제는 다음과 같습니다. “우리가 이 데이터/센서를 이용하여 기계에서 감지할 수 있는 것은 무엇인가?”

프로젝트를 가속화하기 위해, BCDS는 센서 네트워크 개발 키트를 포함하는 플랫폼 구성 키트를 만들었습니다. 이 키트는 모든 종류의 다른 어플리케이션에 대한 광범위 센서를 포함하고 있습니다.

실제로, 프로젝트는 이러한 두 절차의 조합을 이용하여 만들어집니다. 예를 들어 플랫폼은 양 방향에서 접근할 수 있습니다. 플랫폼은 어플리케이션 프로젝트의 상위 집합으로서 위에서 아래로 설계되거나, 기존 기술 구성 요소의 집합으로서 아래에서 위로 설계될 수도 있습니다. 어플리케이션 프로젝트는 전부 하향식으로 솔루션을 정의하지 않습니다. 대신, 그들은 기존 구성 요소, 예를 들어 플랫폼을 사용합니다.

구체적인 예시를 들어봅시다. 우리가 효율적으로 유지 보수 기간을 계획하기 위해, 기계 회전 부분의 마모를 초기에 발견할 수 있도록 하고 싶다고 합시다.

첫째, 이 프로젝트는 가능한 한 독립적으로 정확하게 실행되도록 정의되어야 합니다. 하나의 실행 가능성을 너무 빨리 결정하는 것은 너무 이른 시기에 솔루션 공간을 좁혀버릴 수 있으므로 피해야 합니다.

기능적 요건 외에도, 솔루션 체계를 정의하는 시스템 요건도 지켜져야 합니다. 이는 비용 제한, 시스템 작동 환경, 기존 시스템의 인터페이스 설정을 포함합니다.

Dirk Slama: 그렇다면 좋은 요건은 무엇입니까?

Stefan Schuster and Julian Bartholomeyczik: 핵심 질문은 다음과 같습니다. 사용자가 시스템으로부터 배우고 싶어하는 것은 무엇인가? 시스템이 수행해야 하는 작업은 무엇이며, 언제 그리고 어떤 조건에서 수행해야 하는가? 기본적인 경제 조건은 무엇이며, 어떤 환경에서 시스템이 작동해야 하는가?

이 예시에서, 사용자는 시스템이 적시에 기계 마모에 대해 알려주길 원합니다. 기계는 산업 환경에서 작동됩니다. 우리는 처리 통제 시스템이 이미 존재하며, TCP/IP를 통해 접속될 수 있다고 가정합니다. 우리는 잠재 고객이 기계 모니터링에 기꺼이 지불하고자 하는 가격을 설정하며, 그 결과 센서 노드 제조 목표 가격이 €30가 됩니다. 시스템은 케이블을 사용하지 않고 연결되어야 하며, 배터리 수명은 1 년이 되어야 합니다.

기능 부품의 경우, 우리가 작업을 수행하기 위해 시스템에 필요한 데이터를 유도할 수 있는 이론이 정립된다. 이 예에서, 기계의 마모 및 눈물 이론 상태는 기계 침대에서 증가 진동을 통해 확인할 수 있다. 이론적으로 이런 종류의 보통 (기계 익숙한 즉 엔지니어) 도메인 전문가에 의해 정의된다. 이 예시에서, 이론은 기계의 마모가 기계판에서의 증가된 진동을 통해 확인될 수 있다고 말한다. 이런 종류의 이론은 보통 영역 전문가 (즉, 기계에 친숙한 엔지니어)에 의해 정의된다.

이상적으로, 이론이 먼저 입증되어야 합니다. 이 예시에서, 이는 두 기계를 측정함으로써 이루어집니다. 하나는 적절한 작업 조건에 있는 기계이고, 하나는 당신이 시스템을 확인해야 하는 조건 (부품이 마모되는지)에 있는 기계입니다. 이러한 유형의 입증 절차는 이론을 확인하고 (부품이 마모될 때 진동이 증가한다) 적절한 센서를 선택하기 위해 (센서를 이용하여 테스트 시행) 사용될 수 있습니다. 또한 장착 위치 또는 일련의 적절한 장착 위치가 이 단계에서 결정되도록 합니다. 이러한 위치로부터 다른 변수들은 액체 및 온도에 이용 가능한 공간과 저항 등으로 결정될 수 있습니다.

이론이 검증되면, 디지털 모델로 변환됩니다. 이 예에서 취해진 측정은 진동, 주파수, 마모 정도에 따른 파라미터 변화 정도에 대한 정보를 제공합니다. 이상적으로, 측정은 기계 간 변화를 알아내기 위해 여러 기계에서 취해집니다.

센서는 디지털 모델, 비기능 요건, 검증 프로세스로부터 얻은 경험에 근거하여 선택됩니다. 기존의 데이터 또한 활용될 수 있습니다 (예를 들어, 처리 통제 시스템은 이미 엔진의 회전 속도를 알고 있는가?). 따라서 데이터 수집 지점은 정확하게 명시됩니다. 그리고 최종 단계에서, 시스템은 이제 “솔루션 스케치”에 해당됩니다. 우리의 중점이 백엔드가 아닌, 여기 센서 관점에 있다는 것에 주목해 주십시오.

이 예에서 설계된 센서 시스템은 기계의 축 베어링 지점 가까이에 장착됩니다. 그것은 배터리에 의해 전원이 공급되며 무선으로 데이터를 전송합니다. 여기서 중요한 결정은 디지털 모델이 실행되는 장소와 관련된 것입니다. 다음은 두 가지 가능한 시나리오입니다. 첫 번째 시나리오에서, 모델은 센서 노드에서 실행됩니다. 이는 기계가 일정 마모 수준에 도달 할 때 간단한 메시지가 상위 시스템으로 전송된다는 것을 의미합니다. 두 번째 시나리오에서, 디지털 모델은 중앙 통제 시스템에서 실행되며, 이는 센서 데이터가 전송되고 마모가 상위 시스템에서 계산된다는 것을 의미합니다.

이 결정은 특히 다음 고려 사항에 의해 일어납니다:

• 센서 노드의 에너지 요건: 데이터를 전송하는 것은 많은 에너지를 필요로 한다. 센서 노드를 미리 처리하는 것은 데이터 전송 요구를 감소시킨다.

• 이용 가능한 처리 능력 및 데이터: 데이터 처리가 지정된 경제적 한계 내 센서 노드에 실현 불가능한 처리 능력을 필요로 할 수 있다. 다른 소스로부터 추가적인 데이터가 정확한 계산을 보장하기 위해 필요한 경우, 필요한 모든 데이터가 이용 가능한 곳에서 계산은 수행될 수 있다.

• 노하우 보호 및 공급 부문: 알고리즘이 보호될 필요가 있으며, 그것이 센서 제조자에 의해 만들어졌다면, 그 다음 노드에서의 실행이 일어날 수 있다.

이 예에서, 알고리즘은 모든 필요한 데이터가 이용 가능하고, 처리 능력이 낮으며 전지 수명이 필수적일 때, 센서 노드에서 실행됩니다.

Dirk Slama: 감사합니다. 마지막으로, 솔루션 스케치의 핵심 구성 요소들에 대해 간단하게 이야기해봅시다.

Stefan Schuster and Julian Bartholomeyczik: 주요 구성 요소는 실제 센서 요소인 마이크로프로세서와 무선 통신을 위한 요소입니다. 마이크 및 가속도 센서 테스트에 이어, 주파수 범위와 진폭을 결정한 후, 가속도 센서가 선택됩니다. 마이크로프로세서는 제조업체의 구성 키트 (플랫폼 전략, 상향식 절차 참조)로부터 선택됩니다. 그리고 그 차원은 알고리즘을 실행할 수 있고 일부 개선을 위한 공간이 여전히 존재하는 것입니다. 무선 연결은 범위 요건 및 배터리 사용 요건에 기초하여 선택됩니다. 블루투스 LE (BLE) 연결이 선택됩니다. 게이트웨이는 구현되어 BLE 통해 데이터를 수신하고 처리 통제 시스템과의 연결을 가능하게 하는 와이파이로 변환된다.

초기 솔루션 설계의 결과에 기초하여, 프로젝트 팀은 중요한 ‘생산 또는 구매’ 의사결정을 내려야 한다. 이 결정은 프로젝트에 큰 영향을 미칠 것이다. 한 가지 중요한 요인은 기업 가이드라인 및 정책에 관한 것이다. 또 다른 요인은 전략적인 프로젝트 목표 및 필요한 솔루션 구성 요소의 이용 가능성에 관한 것이다. 일반적인 IoT 프로젝트의 생산 또는 구매 질문들은 다음을 포함한다.

• 공통 규격품 (COTS) 솔루션: COTS 솔루션은 차량 관리, 차량 추적, 스마트 미터링 등의 측면에 이용 가능한가?

• 자산 상 하드웨어: 맞춤형 하드웨어 또는 표준 하드웨어가 사용되어야 하는가?

• 자산 상 소프트웨어: 우리는 사전에 통합된 운영 체제, 펌웨어, 어플리케이션 컨테이너 및 개발 도구를 사용해야 하는가? 아니면 맞춤형 솔루션을 선택해야 하는가?

• IoT 클라우드/M2M 미들웨어: 완전히 발달한 상업적 IoT 클라우드/M2M 미들웨어에 비해 가벼운 오픈 소스 체제를 사용하는 것의 장점은 무엇입니까?

• 무선 통신: 우리는 더 나은 글로벌 커버리지를 보장하기 위해 하나의 통신 사업자에 의존하거나 MVNO (모바일 가상 네트워크 운영자)와 일해야 하는가?

결과에 따라, 또 다른 관련 질문은 일반 계약자의 역할을 해야 하는 주체에 관한 것이다. 예를 들어, 기업 자체, 시스템 총괄자, 또는 통신 회사의 M2M 사업부가 될 수 있다.

초기 솔루션 설계가 완료되면, IoT 프로젝트 개시 단계에서의 최종 작업은 일반적으로 프로젝트의 조직 구조를 설정하는 것이다. 이것이 우리가 여기에서 설명하고자 하는 것이다.

IT는 IoT에 중요한 많은 법칙, 특히 Moore와 Metcalfe의 법칙에 의해 통제된다. 덜 널리 알려졌지만 우리의 경험에서 매우 중요한 이 법칙은 1968년 Melvin Conway에 의해 제시되었다. 이 법칙에 따르면, 소프트웨어 시스템의 구조는 이를 생산하는 조직의 구조를 반영한다. 예를 들어, 세 개의 개발 팀이 IT 프로젝트에 참여하는 경우, 결과로 초래된 아키텍쳐가 세 가지 주요 구성 요소를 가질 가능성이 있다. 결과적으로, 목표가 세 가지 구성 요소로 아키텍처를 만드는 것일 경우, 프로젝트의 조직 구조는 세 개의 개발 팀으로 구성되어야 한다.

이를 염두에 두고, 프로젝트의 조직 구조는 생산 또는 구매 의사결정의 결과뿐만 아니라, 고려 초기 솔루션 설계의 결과를 고려해야 한다. 이는 다시 IoT 솔루션 프로젝트의 최상위 작업 흐름을 구성하는 방법에 대한 논의로 우리를 데려간다.

                       Identifying the right workstreams
                       

Ignite |IoT 방법론은 최상위 프로젝트 구조로 작업 흐름의 개념을 사용한다. 이는 우리가 IoT 프로젝트처럼 많은 종속성을 지닌 복잡한 프로젝트의 경우, 전통적인 폭포수 모형 접근법을 사용하는 경우에도, 개시 단계 동안 완전하고 완벽하게 안정적인 작업 분류 체계 (WBS)을 마련하는 것은 불가능하다고 생각하기 때문이다. 작업 흐름의 개념은 이 프로젝트의 역동성을 더 잘 반영한다. 각각의 작업 흐름은 초기 솔루션 설계 (Conway의 법칙)로부터의 핵심 산출물 집합 (예를 들면 PMI [PM1]에 따라, 작업 패키지로 정의된)에 매핑되어야 하며, 팀과 팀/작업 흐름 관리자를 필요로 한다.

Proposed IoT project workstreams

일반화하는 것은 어렵지만, 우리의 분석은 위의 도표에 설명된 작업 흐름을 정의하는 것이 많은 IoT 프로젝트에 타당하다는 것을 보여 주었다.

1. 프로젝트 관리: PMI PMBOK [PM1]에 잘 정의되어 있지만 처음 6개의 작업 흐름에 걸쳐서 솔루션 아키텍처 관리를 통합할 필요가 있다.

2. 크로스 커팅 작업: 보안, 자산 라이프사이클 관리, 솔루션 통합 및 테스트를 포함하는 다음 작업 흐름에서 종속성을 가지는 작업의 포함

3. 솔루션 인프라 및 운영: 어플리케이션 라이프사이클 관리 솔루션을 포함하는 솔루션 개발 및 운영에 필요한 하드웨어 및 소프트웨어 인프라의 설치 및 관리

4. 백엔드 서비스: 백엔드 서비스의 이행 및 운영, 기존 어플리케이션과의 통합

5. 통신 서비스: 통신 인프라의 설치 및 관리

6. 자산 상 구성 요소: 설계 및 제조 또는 자산 상 하드웨어의 구입 및 구현

7. 자산 준비: 자산 및 새로운 솔루션을 위한 환경의 준비

다음에서, 우리는 핵심 과업과 다른 작업 흐름과의 종속성을 고려하여, 독립적으로 각각의 작업 흐름을 살펴볼 것이다.

프로젝트 관리

폭포수 모형 또는 민첩한 접근법을 기반으로 하든 안 하든, 각 프로젝트는 효율적인 프로젝트 관리 과정을 필요로 한다. PMI, 즉 프로젝트 관리 기관은 프로젝트 관리의 핵심 요소를 정의한다. ” A Guide to the Project Management Body of Knowledge (PMBOK)“ [PM1]에서는 시작, 계획, 실행, 감시 및 통제, 마감을 다섯 가지 핵심 프로젝트 관리 과정으로 본다. IoT 솔루션 프로젝트에 동일한 과정이 적용된다. 표준 과정에 대한 자세한 내용은 PMBOK 가이드를 참조하십시오. 이 시점에서, 우리는 적어도 부분적으로 IoT에 특화되어 있다고 생각하는 특정 프로젝트 관리 작업을 강조하고 싶다. 프로젝트 계획의 경우 다음을 포함한다,

• 조달 계획: IoT 솔루션에 필요한 구성 요소 및 서비스를 조달하는 프로세스의 복잡성은 과소평가되어서는 안 된다 (예를 들어, 자산 상 하드웨어 및 통신 서비스). 따라서 이러한 프로세스는 그에 따라 일찍 시작되고 계획될 필요가 있다.

• 자원 계획: 우리는 이미 IoT 프로젝트의 주요 특징 중 하나가 내장형 소프트웨어에서 기업 소프트웨어로의 통신에 필요한 다양한 기술이라는 것을 알고 있다. 이는 자원 동원 과정을 어렵게 만들고 충분한 시간과 자원이 이 작업을 위해 계획될 필요가 있도록 만든다.

• 품질 관리: QM은 통신 서비스 품질, 평균 자산 상태와 같은 솔루션에 특화된 보고 항목을 포함해야 하는 솔루션을 보고한다

• 솔루션 아키텍처 관리: 이미 이상적으로 초기 솔루션 설계에 대한 책임이 있는 솔루션 설계자는 지속적으로 개인 작업 흐름에 의해 생성된 상세 설계를 검토하고 모든 다른 설계를 하나의 일관된 솔루션에 추가할 수 있도록 해야 한다. 이는 각각의 다른 작업 흐름의 설계적 정렬을 보장하기 위해 아키텍처 검토 과정의 설립을 필요로 한다.

• 인터페이스 관리: 다른 솔루션 구성 요소 및 작업흐름 사이의 효율적인 기술적 인터페이스 (소프트웨어, 통신 프로토콜, 하드웨어) 관리는 모든 분배된 시스템 프로젝트의 가장 중요한 성공 요인 중 하나이다. 우리는 다음 사항을 매우 권장한다.

o 모든 크로스 컴포넌트 인터페이스를 조정하고 지속적으로 다른 작업 흐름과 연락하는 것에 대한 책임을 맡는 특정 역할을 정립

o 각 인터페이스의 기술적, 기능적 설명을 포함하는 모든 크로스 컴포넌트 인터페이스를 수집하는 중앙 저장소를 구축. 그러나 도구의 과잉 사용을 피해야 한다. 중앙 인터페이스 저장소를 만들고 유지하기 위한 유연하고 가벼운 메커니즘으로 위키를 사용하십시오. 이는 REST 및 OPC에서 MQTT 및 CoAP까지 인터페이스들이 매우 여러 다른 종류들로 이루어지는 좋은 기회가 있다는 것을 고려하면, 특히 장치에 특화된 프로토콜과 관련이 있다.

크로스 커팅 작업

그 이름에 충실하게, 크로스 커팅 작업 흐름은 보안, 자산 라이프사이클 관리, 솔루션 통합 및 테스트 작업 흐름 등 모든 다른 작업 흐름을 가로지르는 작업에 책임이 있다.

보안

모든 IoT 솔루션에 대한 보안의 중요성을 감안할 때, 그것을 최고 수준의 작업 흐름 그 자체로 만들자는 강력한 주장이 있다. 그러나, 보안이 각각의 다른 작업 흐름에 영향을 미치기 때문에, 우리는 실제 크로스 커팅 작업 흐름으로 취급되어야 한다고 생각한다.

IoT 보안의 기술적 측면들과 그들이 자산 상 구성요소, 통신 서비스, 백엔드 서비스, 인프라 등 다른 작업 흐름에 영향을 미치는 방법에 대한 더욱 자세한 설명은 조금 더 아래의 보안 기술 프로파일 부분을 참조해주십시오.

보안 작업 흐름의 관점에서, 보안이 단지 기술에 관한 것이 아님을 이해하는 것이 중요하다. 또한 보안은 여기에서 정의될 필요가 있는 모든 보안 정책 및 과정을 필요로 한다. 그리고 이 프로젝트는 솔루션의 보안을 보장하고 검증하기 위한 다음과 같은 전략을 정의해야 한다.

• 위험 평가: 이는 최우선 순위 위협과 가장 가능성이 높은 공격자의 프로파일을 식별하도록 해야 한다. IoT 솔루션의 경우, 이는 분명 자산 관련 영향 분석뿐만 아니라 자산 및 자산 관련 통신에 대한 공격을 포함한다.

• 보안 아키텍처: 다른 보안 메커니즘이 솔루션 아키텍처에 통합되는 방법을 보여주는 전문화된 아키텍쳐 관점.

• 보안 이행: 일반적으로 다른 모든 작업 흐름을 크로스 커팅하고 포함하는 보안 아키텍처를 이행하기 위한 작업 패키지를 포함한 세부 계획.

• 보안 테스트 및 검증: 보안 아키텍처 및 이행에서의 잠재적인 결함을 식별할 수 있도록 하는 전용 테스트 전략. 이는 외부 전문가를 필요로 할 수 있다.

자산 라이프사이클 관리

서론에서의 논의처럼, 많은 IoT 솔루션들이 자산 라이프사이클에 큰 영향을 미치며, 라이프사이클은 통합된 제품/서비스 설계, 제품 제조, 서비스 개발, 마케팅 및 영업, 유통 및 활성화, 서비스 운영, 원격 상태 모니터링, 솔루션 지원 및 제품 유지 관리 (원격 유지 보수 및 예방 정비 포함), 디지털 서비스, 재판매 및 은퇴에 이른다.

우리는 모든 작업 흐름을 포함하는 자산 라이프사이클 관리의 관점에서 솔루션을 찾을 책임이 있는 프로젝트 내 지정된 역할을 만들도록 권장하며, 이는 이 중요한 관점이 끝에서 끝까지 다루어지는 것을 보장한다.

자산 활성화를 예로 들어보자. 라이프사이클의 중요한 부분은 보통 자산 상 소프트웨어, 통신 서비스, 백엔드 서비스에 영향을 미친다. 그래서 최선의 해결책이 모든 작업 흐름을 통해 이행되는 것을 보장하기 위해, 중심화된 관점에서 이를 보는 것이 합리적이다.

솔루션 통합 및 테스트

마지막으로, 솔루션 통합 및 테스트는 또 다른 중요한 크로스 커팅 작업이다. 책임이 있는 사람 또는 팀은 핵심 출시 이정표, 인터페이스 버전, 준비 메커니즘, 프로세스, 끝에서 끝까지의 테스트 계획 등에 동의하기 위해 모든 다른 작업 흐름과 연락을 취하도록 요구될 것이다. 또, 이는 여느 큰 기업 IT 프로젝트와 너무 다르지는 않으면서, 테스트 계획과 자산 상 구성 요소를 통합해야 하는 복잡성이 추가된 프로젝트이다.

현장 환경을 완전히 반영하는 테스트 환경을 만드는 것이 항상 가능한 것은 아니다. 당신이 1,000,000개의 장치를 관리하는 작업의 IoT 솔루션을 가질 경우, 1,000,000개의 테스트 장치로 이 솔루션을 테스트하는 것은 실현 불가능할 것이다. 대신, 실용적인 메커니즘이 제한된 수의 실제 장치를 사용하여 초기 통합 테스트의 완성을 가능하게 하도록 발견되어야 할 것이다. 부하 생성기는 1,000,000개의 장치로 시스템을 모의 실험하는데 사용될 수 있으며, 따라서 백엔드 시스템의 확장성을 테스트할 수 있다.

마찬가지로, 효율적인 테스트 전략은 통신 서비스를 위해 고안되어야 할 것이다. 세계적인 출시를 계획하는 경우, 모든 위치를 테스트하는 것이 항상 가능하지는 않을 것이다. 이 경우, 테스트 팀은 합동 테스트 계획을 정의하기 위해 서비스 제공자와 함께 밀접하게 일하도록 요구될 것이다.

다시 이러한 종류의 통합 테스트는 보통 다른 모든 작업 흐름에 영향을 미치기 때문에, 크로스 커팅 작업 작업 흐름 하에서 이러한 작업을 집중화하는 것이 합리적이다.

솔루션 인프라 및 운영

이 작업 흐름은 솔루션을 구축하고 테스트하고 운영하는데 사용되는 전체 인프라를 설정할 책임이 있다. 특히, 모든 기업 소프트웨어 프로젝트에서 발견되는 표준 인프라 설정 작업을 포함한다. 그러나, 이러한 표준 작업 외에도, IoT 솔루션에 특화된 많은 작업들이 있다.

표준 기업 어플리케이션의 경우, 필요한 다른 환경들, 보통 개발, 테스트/통합 및 생산에 합의하기 위해 이 작업 흐름은 긴밀히 협력하는 개발 프로젝트의 구성원과 운영 팀의 구성원을 필요로 한다. 그들은 또한 여러 개발 업데이트를 새로운 출시와 통합시키고 궁극적으로 생산 환경에서 새로운 출시를 이용 가능하게 만드는 필요한 관련 준비 과정에 동의해야 한다.

구성 관리 및 출시 계획뿐만 아니라 정상 상태 및 운영 계획 또한 이 작업 흐름의 일부를 형성한다. 하드웨어 크기 조정 및 획득, 백업 관리, 보안 인프라 (방화벽, DMZ 등), 시스템 모니터링, 경보 관리, 확장성 계획, 가용성 관리 (예를 들어, 지역 회복력을 가진 각 주요/재해 지역), 고객 지원 센터 기능 등의 작업도 고려되어야 할 필요가 있다. 솔루션이 클라우드를 기반으로 하는 경우, 클라우드 인스턴스 상태 모니터링, 클라우드 SLA 관리, 클라우드-2-기업 어플리케이션 통합 또한 고려되어야 한다.

심지어 표준 프로젝트의 경우, 여기에 포함된 다양한 기술, 도구, 개념, 사람은 복잡한 시나리오를 구성한다. IoT 솔루션 경우, 이러한 솔루션의 고도로 분산된 특성 때문에, 당신은 이 모든 것 이상을 가진다.

이 작업 흐름은 모든 복잡성 속에서 어플리케이션 라이프사이클 관리 (ALM)가 백엔드에서 자산까지 일관되게 적용되도록 해야 한다. 이는 자산, 자산 모니터링, 자산에 의해 생성된 에러 및 경보 관리 등을 위해 필요한 소트프웨어 업데이트 인프라의 제공을 포함한다.

또 다른 중요한 문제는 고객 지원 인프라에 관한 것이다. 대부분의 통신 사업자는 그들의 지원 팀에게 기본 장비 검사를 할 수 있는, 예를 들어 온라인 상태인지 여부를 검사하는 DSL 모뎀 “핑잉” 등의 특수 도구를 제공한다. 이 기능은 보통 고객 접촉 이력 등의 추가 정보를 제공하는 핵심 콜 센터 어플리케이션에 들어가 있다. 많은 IoT 솔루션이 이 작업 흐름에서 다루어질 필요가 있는 유사한 지원 기능을 필요로 할 것이다.

IoT 솔루션이 예를 들어 원격 상태 모니터링 (RCM) 또는 예측 유지 보수 기능을 제공하여 기존의 현장 서비스 팀을 지원하도록 설계된 경우, 이 팀에의 기술적 훈련 제공도 매우 중요해질 것이다.

백엔드 서비스

백엔드 서비스 작업 흐름의 일반적인 작업 항목은 자산 및 자산 데이터, 솔루션에 특화된 프로세스의 이행, EAI (기업 어플리케이션 통합) 또는 SOA (서비스 지향 아키텍처)를 통한 기존 어플리케이션과의 통합을 위한 솔루션의 생성을 포함한다.

전문 M2M/IoT 어플리케이션 플랫폼 (자세한 사항은 기술 프로파일 부분 참조)을 사용하는 경우, 당신은 이 플랫폼을 선택하고 획득하고 설치해야 할 것이다. 처음부터 시작하는 경우 프로세스는 몇 주가 걸릴 수 있으며, 특히 전략적 기술 결정일 경우 몇 개월이 걸릴 수 있다.

목표는 모든 현장 자산의 중심적 대표를 포함하는 백엔드에 특정 단계을 구축하는 것이다. 이는 개별 자산 또는 자산 그룹을 위한 관리 기능뿐만 아니라 최신 자산 상태 데이터 및 상세한 자산 사건 이력을 포함한다. M2M/IoT 어플리케이션 플랫폼은 동떨어진 자산과 통신하고 지역적으로 자산 데이터를 관리하기 위한 방법 등 이러한 기능을 구현하기 위한 아웃 오브 박스 기능을 일반적으로 제공할 것이다. 이 플랫폼은 배치된 모든 자산 및 해당 상태에 대한 개요를 제공하는 관리 콘솔을 종종 포함한다.

백엔드 서비스 작업 흐름은 각 자산과 자산에 배치된 장치에 적합한 프로파일을 작성해야 한다. 그 다음, 프로파일은 플랫폼에서 이행되어야 할 것이다. 이는 예를 들어, 플랫폼에 의해 제공된 도구를 사용하여 수행될 수 있다.

대부분의 경우, 관리 콘솔은 최종 사용자에게 적합하지 않을 것이므로, 솔루션에 특화된 UI가 구현되어야 할 것이다. 이는 솔루션에 특화된 프로세스가 구현되어 있는 전문 어플리케이션의 일부가 될 수 있다. 이러한 프로세스는 대부분 기존의 많은 기업 어플리케이션과 통합되어야 할 것이다.

예를 들어 카셰어링 서비스의 경우, 첫 번째 단계는 백엔드에서 동떨어진 자산 (이 경우 자동차)의 중앙 모델을 만드는 것을 포함한다. 그리고 카셰어링 고객을 위한 UI 및 어플리케이션의 구현으로 이어진다. 그 다음, 모바일 어플리케이션은 자동차가 지도에 가시화될 수 있도록 현재 차량 위치에 대한 데이터를 얻을 수 있는 중앙 자산 저장소에 접근한다. 또한 어플리케이션은 자동차 예약 기능을 지원할 필요가 있다. 결제 과정의 경우, 기존 어플리케이션과 통합된다. 웹 UI는 상세한 차량 사용 이력을 사용자와 콜 센터 직원들에게 제공한다. 이 데이터는 자동차 대여 과정의 시작 및 종료를 알리는 사건 등 차량에 내장된 장치로부터 수신된 사건에서 끄집어내진다.

또 다른 주요 업무는 일반적으로 사용자 관리 시스템과 솔루션의 통합을 포함한다. 가장 간단한 사례로, 이는 사용자 등록 및 로그인을 위한 웹 기반 솔루션을 필요로 한다. 위의 카셰어링 서비스 등 많은 예에서, 이는 더 복잡해질 수 있다. 예를 들어, 사용자의 운전 면허증을 확인하고, 자동차를 열기 위한 칩 카드를 발급하는 보다 정교한 등록 절차의 설정을 포함할 것이다.

통신 서비스

자산 및 백엔드 사이에서 통신 서비스를 설정하고 관리하기 위한 작업 흐름의 구조는 많은 요인, 특히 요구되는 글로벌 커버리지, 최대 대기 시간 및 대역폭, 비용 등에 따라 달라질 것이다 초기 솔루션 설계에 기초하여, 이 작업 흐름은 통신 서비스에 대한 최적의 설정을 알아내기 위해 더 심도 있는 분석을 완성하는 것에 관한 것이다. 이는 다음과 같은 작업을 포함할 수 있다.

• 예상 트래픽 프로파일과 백엔드 연결 및 위치를 포함하는 범위/서비스에 대한 자세한 요건을 수집

• 하드웨어 기능 분석, 지원된 통신 서비스를 기반으로 한 하드웨어 선택에 대한 가능한 지원, 모바일 네트워크와 로밍의 통합

• 통신 규제 및 특정 수직적 규제를 포함하는 출시 시장의 규제 상황 확인 (예를 들어, eCall 서비스에 대한 국가 별 규제)

• 데이터 크기, 필요한 회복력, 예외 처리 등 통신 행동과 네트워크에의 잠재적인 영향을 감시

이 정보는 올바른 기술과 통신 서비스 제공자를 선택할 토대를 제공할 것이다. 시간이 제공자를 고르고 서비스 계약에 대해 협상하는 데 필요한 시간은 과소평가되어서는 안 된다.

개발 단계에서는 서비스 제공자가 테스트 환경을 이용 가능하게 만드는 것이 중요하다. 전반적인 솔루션은 통신 서비스 제공자의 인프라에 통합되고 테스트되는데 필요할 것이다. 이는 예를 들면, 연결성 관리를 위한 작동자 전용 포탈을 사용하여 행해질 수 있다.

가동기간 동안, 같은 포탈이 제공 상태, 기기 데이터 사용, SIM상태, 네트워크 오류 등을 포함하는 통신 네트워크를 감시하고 관리하는데 사용될 수 있다.

Aeris의 Director of Sales Engineering인 Stephen Blackburn 과의 다음 인터뷰는 이 주제에 대한 더 가치 있는 통찰을 제공한다.

Jim Morrish: 솔루션의 모바일 통신 부분 계획과 시행에서 프로젝트 관리자의 체크 목록에 대한 주요 포인트는 무엇입니까?

Stephen Blackburn: 이 프로젝트 관리자는 모바일 통신 솔루션의 개발을 처음부터 끝까지 이끌고 작동하는 광범위하게 다양한 요소들을 이해하는 시야를 가지기 위해 이해와 통찰을 가져야 합니다. 그는 다음 고려사항들을 감독해야 합니다

1) 장보러 가는 사업 모델– 어떻게 회사가 그들의 고객을 변화시킬 것인가

2) 어플리케이션 통신 호출 흐름– 어떻게 기기가 네트워크와 상호작용할 것인가

3) 일반 작동 패턴과 무선 업그레이드를 포함하는 예상되는 사용 패턴의 정의

4) 공급 체인 계획, 기기 제조의 고려, 통신사 네트워크상의 기기 공급, 제조과정 끝에서 통신 연결 테스트, 시장 목표에 대한 채널

5) 휴대 통신사 선택

6) 휴대 통합 (API 통합)

7) 다양한 RF 상태에서의 통신 연결 테스트를 포함하는 양단간 어플리케이션 테스트 계획

8) 기기 통신 증명

9) 이해되고 준비된 통신 지원 SLA

10) 고객 지원 과정 정의와 지원 팀 훈련

Jim Morrish: 모바일 통신 작업 흐름과 다른 작업 흐름간의 주요 인터페이스, 즉, 자산 하드웨어, 보안 등은 무엇입니까?

Stephen Blackburn: PM은 어떻게 모바일 통신 계획이 다른 사업의 부분에 영향을 주는지에 대해 알고 있어야 합니다. 그래서 이들 다른 그룹들이 계획과 실행에 그들의 요구사항이 맞는가에 대한 보장에 더해 조언을 줄 수도 있어야 합니다. 주요 교차되는 영역은 포함합니다

• 규제 승인

• 제조와 공급 체인

• 보안

• IT 시스템

• 작동과 지원

• 재정

Jim Morrish: 솔루션 테스트, 특히 모바일 통신 부분에 대한 조언을 줄 수 있습니까? 어떻게 테스트가 이 종류의 환경을 변화시킵니까?

Stephen Blackburn: 포괄적인 테스트가 열쇠입니다. 제품의 핵심 기능을 테스트하는 것이 중요할 뿐 아니라, 솔루션이 LAN에 다양한 특성을 가진 휴대 네트워크에서 잘 작동하는가를 보장하는 것도 필수적입니다.

솔루션 테스트에 더해, 기기가 특정한 통신사 네트워크에 허락을 받기 위해 통신사 증명을 통과하려 한다면, 통신사는 당신의 기기가 네트워크상의 “좋은 시민”인지를 체크하려고 할 것입니다. 한 사례는 기기가 당신의 데이터 중심상의 어플리케이션 서버에 연결하는데 실패했을 경우의 재시도 알고리즘의 행동일 수 있습니다. 이 점에서 판독기는 “왜 통신사가 신경 써야 하지?” 라고 의문을 가질 수 있습니다. 그것은 통신사가 네트워크 용량, 그들 무작위 분산이 뒤따르는 네트워크에 사용자 접근을 상정하는 것을 위해 디자인하는 것입니다. 만약 모든 사용자가 네트워크에 동시에 접속하려고 한다면, 혼잡으로 인해 다른 사용자의 서비스 접근이 막힐 것입니다. 그러니 당신이 100,000혹은 수백만 개 기기의 거대한 롤아웃을 계획하고 있다고 상상해 보십시오. 만약 당신의 데이터 중심이 당신의 모든 배치된 기기들이 네트워크와의 연결을 동시에 잃는 중단사태를 경험하고 그것들이 모두 즉시 재시도하고 실패하고 다시 즉시 재시도하고 실패하기를 계속하여 동시에 지역 송신탑과 통신사 네트워크 인프라에 다른 사용자들에게 혼잡을 야기할 수 있는 부담을 줄 수 있습니다. 그러므로 무작위적 후퇴 알고리즘의 디자인과 사전 증명 테스트는 좋은 생각입니다.

솔루션 테스트는 보통 통제된 환경에서의 연구소 테스트를 포함하지만 그것이 후에 배치될 환경에서 솔루션을 테스트하는 현장 테스트 단계를 포함시키는 것도 중요합니다. 연구소 테스트 단계 동안 엔지니어들은 일반적으로 기기가 좋은 휴대 연결을 제공하고 무선 인터페이스에서 지속적인 데이터 비율을 달성할 좋은 신호 수준을 가지고 있다고 보장합니다. 이건 기본적인 테스트로는 좋지만 때로 현장에서 나타나고 낮은 대역폭과 긴 대기 환경을 만드는 나쁜 질의 신호 환경을 강요하는 부정적인 테스트 사례도 도입되어야 합니다. 근 실시간 통신을 요구하는 어플리케이션은 이런 환경에서는 적절히 작동하지 않을 수도 있으므로 어플리케이션을 디자인하고, 기술(2G, 3G, LTE 모든 다양한 대기 특징)을 선택하고, 어플리케이션을 테스트할 때 이를 고려하는 것이 중요합니다.

연구소 테스트가 끝나고 모든 것이 예측대로 작동될 것으로 추정되면, 기기가 예측대로 대부분 작동하리라는 고수준의 신뢰도가 있을 것입니다. 하지만, 연구소에서는 이루어질 수 없는 그런 5%의 테스트 사례가 있고 현장 환경에서 발견되는 사건의 합류지점만이 그런 사례를 드러냅니다. 그러므로 솔루션 개발을 설명하는 모든 사용 사례에 대해 생각하는 것이 중요하고, 그런 사용례를 테스트할 한정된 파일럿 배치에 대해 좀 더 생각하고 계획해야 합니다. 테스트 장소는 나쁘고 좋은 휴대 신호 질을 포함해야 한다. 작은 기기 인구에 대한 현장 테스트는 어떻게 기기 인구가 시작 후 행동할 것인지에 대한 조짐을 제공할 것입니다. 적절한 샘플 크기와 배치 환경 선택을 당신에게 제공하면 당신은 당신 기기의 오차범위내인 1%에 문제가 있을 때 같은 문제를 1%의 당신 기기에서 보게 될 것이다. 당신이 문제를 다룰 수 있고 수용 가능한 여지까지 문제 기기 수를 얻을 수 있다면 작동 후 문제 있는 기기의 비율이 관리 가능하게 남으리라는 높은 수준의 신뢰도가 있습니다.

Jim Morrish: 솔루현 배치와 예비단계에서 피해야 할 위험이 있습니까?

Stephen Blackburn: 배치 중에 일어날 수 있는 문제는 어플리케이션과 배치 모델 모두에 의존한다. 예를 들어, 기기가 소비자에게 가정에 배치되는 솔루션으로 팔리면 주택 소유자의 일부는 그 기기를 가정 내 가장 통신 전파 범위가 나쁜 곳(지하)에 둘 것이 분명합니다. 어디에 기기를 두어야 할 지에 대한 간단한 설명을 제공하는 것이 중요합니다. 예산 안에 있다면 사용자가 그것을 배치할 때 전파가 충분한 영역에 그것을 두어야 한다는 것을 알려주는 충분한 어떤 표지를 기기에 다는 것이 종종 가치 있을 것입니다.

다른 어플리케이션들은 기기가 맨홀처럼 기지국 전파 범위에 최적이 아닌 곳에 배치되는 것을 요구할 수도 있습니다. 이런 종류의 어플리케이션들은 일반적으로 현장 기술자들에 의해 설치되므로 그들이 그 지역에 걸친 네트워크의 신호 질을 측정할 수 있는 네트워크 스캐닝 도구를 장비하는 것이 중요합니다. 기술자들은 이것을 그 자리의 신호 질을 결정하고 최선의 장소를 정하는데 사용해야 합니다.

Jim Morrish: 가동 준비가 된 후에는 어떻습니까– 계획하는데 중요한 것이 무엇입니까?

Stephen Blackburn: 만약 솔루션이 파일럿 현장 테스트 단계를 완료했다면 작동 후의 주요 문제들의 위험은 크게 줄었을 것입니다. 하지만, 테스트 중에 당신이 문제가 없으리라고 확신했다 하더라도, 어떤 최종 소비자들이 “작동자 오류” 종류를 포함하는 문제를 겪을 수도 있습니다. 그러므로 적절한 지원 과정을 설치하고 소비자의 불가피한 호출을 다룰 지원 팀을 훈련시키는 것이 필수적입니다So it is essential to setup appropriate support processes and train the support team to handle the inevitable calls from customers.

지원 인력들은 일반적으로 제품 특징과 어떻게 그것들을 작동시키는가에 관해 훈련을 받지만 또한 지원팀(보통 2단계)이 어떻게 연결 문제를 진단할지를 훈련 받는 것도 매우 중요합니다. 이것은 가능하다면 가방에 풍부한 진단 도구가 있는 것이 큰 도움이 될 것입니다. 만약 당신의 2단계 엔지니어가 포탈에 로그인해 문제 있는 기기가 통신사 네트워크에 등록되었는지를 확인하고, 데이터 세션을 시작하고 그들은 최근 행동을 발견할 수 있다면, 그들은 즉시 조사를 문제의 뿌리에 집중하고 고객에게 빠른 피드백을 제공할 수 있을 것입니다. 만약 이들 도구들이 이용 가능하지 않다면 통신사에 전화하는 것이 도움이 되겠지만 일반적으로는 더 많이 느려질 것입니다.

자산 요소

초기 솔루션 디자인 단계에서의 입력에 기초해, 이 워크스트림은 자산 하드웨어와 소프트웨어의 디자인을 끝내는 것과 관련된다. 이는 하드웨어 제조, 지역 통신, 펌웨어와 소프트웨어의 선택과 실행, 통합과 테스트를 포함시킬 수 있다.

자산 하드웨어

이상적으로는, 게이트웨이와 다른 자산 하드웨어에 더해 요구되는 센서와 반응기는 이미 초기 솔루션 디자인 단계의 일부로서 확인되었다. 이 워크스트림의 일부로서, 추가 테스트와 평가는 일반적으로 모든 요소가 함께 적절히 작동함을 보장하기 위해 수행될 필요가 있을 것이다. 자가제조와 구입의 의사결정 결과에 따라, 외주 과정은 요구되는 하드웨어 부품의 외부 조달을 위해 시작될 수 있다. 대신, 하드웨어 제조와 테스트 과정으로 이어지는 하드웨어 디자인과 시제품과 과정을 시작할 필요가 있을 수 있다.

자산 작동 시스템과 어플리케이션 컨테이너

작동 시스템과 어플리케이션 플랫폼 혹은 커네이너의 선택은 하드웨어의 선택과 밀접한 관련이 있다. 많은 M2M/IoT 하드웨어 제공자들은 몇몇은 원격 관리와 원격 펌웨어 업그레이드가 가능한 백엔드 관리 서비스까지 지원하는 통합된 솔루션을 제공한다. 우리가 솔루션 인프라 워크스트림 하의 어플리케이션 라이프사이클 관리에 관련된 모든 작업을 그룹화했음에도 불구하고 이들 두 워크스트림에는 강한 의존성이 있다. 같은 것이 어플리케이션 어플리케이션 플랫폼에서 구동되는 소프트웨어 라이프사이클 관리에도 적용된다. 최종적으로, 로컬 데이터의 백업과 복원 기능의 실행은 이 점에서 다루어질 수 있어야 한다.

자산 미들웨어

만약 당신이 M2M이나 IoT 미들웨어를 사용하고 있다면, 이 미들웨어의 특정 자산 요소는 미리 설치되어 설정되어야 한다.

당신은 또한 이 미들웨어를 위한 통신 프로토콜과 보안 증명 관리 보장을 설치하고 설정할 필요가 있다. 이들 작업은 횡절 작업과 솔루션 인프라 워크스트림에 강한 독립성을 가질 수 있다.

유사하게, 어플리케이션 소프트웨어의 분배와 업데이트를 위한 로컬 과정은 테스트되고 솔루션 인프라 워크스트림이 제공한 백엔드 솔루션에 통합되어야 한다.

기기 통합

많은 사례에서, 자산 미들웨어는 하드웨어 전용 드라이버의 실행을 요구할 것이다. 그로 인해 여러 기기가 제공한 데이터와 서비스는 동종 포맷의 백엔드에서 사용가능해질 수 있다. 이들 로컬 드라이버와 프로토콜의 디자인과 실행은 과소평가되어서는 안된다.

또한 초기 솔루션 디자인 단계에서 이루어진 특정 인터페이스의 접근가능성에 대한 추정은 옳지 않을 수 있다. 만약 자산이 특정 인터페이스를 제공할 필요가 있다고 밝혀진다면 이 정보는 자산 준비 워크스트림으로 돌려보내질 필요가 있을 것이다. 예를 들어, 우리는 우리의 사례 연구중 하나에서 초기 디자인이 자산은 사례로 드러나지 않은 배터리 건강 데이터에 접근을 허용해야 한다는 가정에 기반함을 보았다. 이 특정 상황에서, 자산을 업그레이드하는 데에는 시간이 좀 걸리므로 차례차례 전체 솔루션의 롤아웃에 영향을 주었던 이 인터페이스를 제공할 수 있었다.

자산 사업 논리

자산 사업 논리의 실행은 이 워크스트림의 다른 주요 작업이다. 이는 낮은 수준의 내장 소프트웨어에서 지역 사업 규칙과 데이터 관리를 포함하는 복잡한 사업 논리까지 다양하다. Cisco 같은 회사들은 막대한 양의 데이터를 게이트웨이에 저장하고 지역적으로 처리할 수 있는 강력한 게이트웨이가 달린 “포그” 컴퓨팅 개념을 추진하고 있다. 이는 기능 디자인 과정에 대한 우리의 논의에 관련될 수 있다; 특히 자산 소프트웨어와 백엔드 간의 데이터와 논리 분배에 말이다. 기능 디자인이 초기 제안을 제공하는데 반해, 상세한 내용은 이 워크스트림에서 결정되어야 한다. 데이터와 논리 분배는 백엔드 워크스트림에도 영향을 주기 때문에, 밀접한 두 워크스트림 간의 상호작용이 요구된다. 또한, 우리는 중앙 인터페이스 관리를 프로젝트 관리 과정의 일부분으로 실행할 것을 추천한다 (아래를 보라).

백엔드 통합

자산과 백엔드를 통합하는데 있어, 요구되는 프로토콜은 자산에서 지역적으로 이용가능해야 한다. 예를 들어, 어떤 게이트웨이들에는 이것이 항상 주어지는 것은 아닐 수도 있다. 다른 중요한 작업은 적절한 증명과 승인 절차의 규정을 포함한다. 규칙상 사용자 관리는 또한 중앙 백엔드 기능과 동시통합될 필요가 있다.

자산 준비

서문에서 논했듯이, Ignite | IoT 방법론은 IoT 프로젝트가 만들어지고 있는 자산 솔루션을 담당하는 주요 조직으로부터 독립되어 시행된다고 가정한다. 이것이 자산과 IoT 솔루션 사이의 조직 인터페이스를 대표하기 때문에, 자산 준비 워크스트림은 매우 중요하다. 그것을 명쾌한 워크스트림으로 만들고, 누가 소유하고 누가 기여해야 하는지를 분명하게 확인하는 것이 중요하다. 기여는 일반적으로 자산 팀과 솔루션 팀 모두에게서 나온다. 전반적인 소유권은 이 두 팀 중 하나에 맡겨져야 한다.

자산 준비 워크스트림은 자산과 분석, (잠재적으로 통합된)디자인, 자산 제조, 솔루션 시행, 지원, 작동을 포함하는 솔루션의 전체 라이프사이클을 보아야 한다.

분석 단계 중에, 자산-그리고 잠재적으로 그 환경-은 안테나, 센서, 표지, 게이트웨이 등 같은 솔루션의 자산 하드웨어 부품을 도입하는 최선의 방법을 정하기 위해 분석될 필요가 있다. 이는 지역 버스 연결과 전력 공급에 대한 접근 같은 측면의 고려를 포함한다.

만약 솔루션이 전문화된 네트워크를 요구한다면, 이 네트워크의 설치를 위한 요구조건은 조사될 필요가 있다. 만약 솔루션이 실내 위치에서 표지(혹은 유사한)에 의존한다면, 표지 위치에 대한 정확한 위치의 데카르트 좌표가 포착될 것이다.

만약 자산이 밑바닥부터 디자인되거나 IoT 솔루션에 맞추어 수정된다면, 명쾌하게 정의된 기술적 인터페이스(하드웨어나 소프트웨어 수준에서)에 더해 디자인 단계에서 두 팀간의 밀접한 조정이 필요할 것이다

자산과 IoT 솔루션간의 통합이라는 면에서, 자산의 EBOM(Engineering Bill of Material)을 고려하는 것은 가치가 있다. 자산은 일반적으로 PLM(혹은 유사한) 시스템에 저장된 완전한 EBOM을 가진다. IoT 솔루션에 있어, BOM은 다른 부분들로 잘 구성될 수도 있다: 내장 하드웨어, 내장 소프트웨어, 백엔드 소프트웨어의 예처럼 말이다. 자산을 위한 EBOM은 최소한 내장 하드웨어에 대한 언급을 포함해야 한다.

결정은 자산의 제조 과정과 관련되어 이루어질 필요가 있다. 자산 하드웨어 부품이 자산 제조 과정의 일부로서 부착되었는가? 혹은 이들이 나중에 새로 장착되었는가? 어떤 경우에든 자산 부품의 공급은 공급 체인 과정에서 고려되어야 한다. 또한 특별한 조립 기능이 요구될 수도 있고 공급은 그것을 안전하게 만들기 위해 필요로 할 수도 있다.

새로 장착하는 접근법의 면에서, Purfresh 사례 연구는 흥미로운 예시를 제공한다. 이 사례에서, 전문화된 기기들(게이트웨이와 센서)은 화물선상에 새로 장착되어야 한다. Purfresh는 컨테이너 선이 솔루션이 설치될 항구에 정박하는 짧은 기간 내에 이 일을 수행하는 대리인을 다루는데 전문화된 과정을 준비한다. 이 과정이 지역 조립만을 포함하지 않고 활성화와 테스트도 포함한다는 것을 유의하라.

최종적으로, 많은 IoT 솔루션들이 판매 후 과정을 향상시키기 위해 디자인된다. 이는 원격 상태 감시, 예측 관리, 심지어는 디지털 판매 후 서비스(서론을 보라)까지 포함할 수 있다. 자산 준비 워크스트림은 새로운 능력과 매끄러운 도입에 관련된 조직 팀들을 훈련시키는 일을 책임질 필요가 있다 – 새로운 조직 단위를 만드는 점에서 필요하다면.

IoT 프로젝트를 위한 계획/개발/가동에 대한 우리의 논의를 마무리 짓기 위해, 우리는 Managing Consultant at Holisticon AG인 Christian Weiss가 우리에게 쓴 공개 서한을 공유하고자 한다. 우리는 이것이 “두 세계의 충돌” 범주에 대한 매우 좋은 공헌이라고 생각한다.

Ignite | IoT 방법론의 친애하는 저자들에게,

내 불평을 시작하기 전에, 당신들이 처음으로 IoT 방법론을 출판할 수 있게 된 것을 축하하게 해달라. IoT 요구의 증가하는 중요성은 그런 방법론을 요구한다. 당신들의 책과 웹사이트는 매우 가치 있는 공헌이다.

하지만, 당신들의 접근법에 한 중요한 문젯거리가 있다 – 그리고 그것은 나에게 중요하다. 당신들은 맞게 말하고 있듯이, IoT 프로젝트들은 다원칙이고 그렇기 때문에 IoT 방법론은 다양한 기능과 원칙을 결합시켜야 한다. 가장 경험 많은 프로젝트 매니저들은 이것만으로도 큰 위험을 나타낸다는 것에 동의할 것이다. 거기에 더해, 현재의 IoT 프로젝트들은 보통 많은 새롭고 선도적인 첨단 기술을 다루어야 하며, 이는 프로젝트 위험을 더 증가시킨다. 물론 이들 큰 위험은 거대한 기회와 함께 온다; 하지만 그럼에도 이들 위험은 효과적으로 관리되어야 한다.

문제는 당신들이 계획/개발/가동 은유로 단순화시킨 내 의견이 IoT 프로젝트 관리에 대한 폭포 접근을 암시한다는 점이다. 공정하게 말하면, 당신들은 또한 서문에서 Agile이 IoT 프로젝트 관리자의 여러 옵션 중 하나라고 언급하고 있다. 하지만, 당신들은 그것을 뒷받침할 강한 사례를 만들지 않는 것 같다.

계획/개발/가동 은유는 추상적인 관리 수준에서는 유용할 수 있고 원칙적으로는 틀리지 않았다. 하지만, 나는 그것이 과도한 단순화이며 매우 위험한 것이라고 생각한다. 이 위험은 관리가 쉽게 IoT 프로젝트처럼 고위험이 깔려있는 완전하고 상세한 계획을 만들어 낼 영감을 얻고 그 계획을 단계적으로 실행하는 것만이 문제라는 것이다. 만약 이것이 방법론으로 만들어진다면, 나는 내가 여전히 이 접근법을 따르는 프로젝트를 발견하는 것에 놀라지 않을 것이다.

당신들의 계획/개발/가동 접근법 요약은 IoT 프로젝트가 다른 프로젝트처럼 초기 개발 단계에서 시작해 첫 출하 결과 단계로 이어지고 롤아웃과 유지로 이어진다고 묘사한다.

안돼! 그 짓을 그만둬! 단계는 항상 기간과 관련된다. 결과적으로, 계획 단계는 할 일이 계획하는 것뿐이고 개발하지 않는 기간으로 이해되어야 한다. 그리고 개발 단계는 할 일이 개발뿐이고 계획은 안 한다고 암시한다. 나는 이것이 당신들이 암시하는 바가 아니기를 정말로 바란다!!! 계획/개발/가동은 단계가 아닌 원칙으로 보여야 한다. 현실에서는 정말 끝까지 능동적으로 계획하기 때문이다. 그리고 개발 단계는 바라건대 또한 아주 초기부터 시작되어야 한다.

물론 Agile 접근 또한 단계를 알고 있다. 하지만 그 단계들(즉, 기간)은 실행되는 작업에 의해서는 그다지 정의되지 않는다. 대신에, 이들 단계들은 목표, 우선순위, 아티팩트의 종류, 팀 구조 등 다른 특징들을 통해 정의된다. 이것이 이들 단계가 Agile 접근법에서 다르게 불리는 이유이다.

또한 당신들의 서문에는 나를 거의 화나게 만든 다른 한 문장이 있었다: “고정 원가 프로젝트는 종종 폭포 접근을 사용한다”. 불행히도, 이 등치 “고정 원가=폭포”는 여전히 Agile과 고정 원가는 함께 할 수 없다고 주장하는 느림보들을 지원한다. 그건 내 의견과 경험상으로는 완전히 넌센스다!

오해하지 말라: 예산 디자인은 완전히 적합한 요구이다. 하지만, 고정원가는 세세한 디자인 선불을 마무리 짓는 문제가 아니라 프로젝트 전체에서 엄중한 우선 순위 매김의 문제이다. 그리고 이것이 바로 Agile이 투자된 것이다. 나는 그 반대를 주장할 것이다: 고정 원가 프로젝트에 Agile 접근법을 사용하는 것이 성공 확률을 크게 증가시킬 것이라고!

이제 충분하다: 여전히 폭포 접근법을 자주 사용하는 몇몇(특히 큰) 회사들이 그곳에 있긴 하지만 말이다. 하지만, 내 생각에 새로운 방법론은 세계의 개선을 목표로 해야 한다. 그러니 Agile을 IoT 프로젝트의 표준으로 만들지 않겠는가? 내 선의의 비판은 IoT에서 Agile을 지지하는 명쾌한 위치를 주장하는 반면, 당신들의 것은 누구에게나 모든 것에게나 열려있다. 그리고 당신들은 그래서는 안 된다: Agile 접근법은 위험을 관리 가능하게 하는 것을 목표로 한다. Agile의 강점은 바로 미지의 것이 많은 고도로 역동적인 상황에 있다– 그러니 IoT가 아니면 어디에 디폴트가 되겠는가?

나의 제안은: Agile을 Ignite의 디폴트로 하라는 것이다. 그리고 전통적 접근법도 지원되지만 IoT에서 추천되지는 않는다는 회고주의자들을 위한 각주를 달아라.

Best regards,

Christian Weiss

IoT 솔루션 라이프사이클의 계획/개발/가동 관점에 대한 논의를 가졌으니, 우리는 이제 IoT 블록 만들기라고 부르는 것을 소개하고자 한다. 본질적으로, 이들은 우리가 이미 계획/개발/가동 관점의 일부로 보여주었던 어떤 아티팩트 종류의 정식 정의이다.

첫 블록 만들기는 IoT 프로젝트 차원이라고 명명된다. 이들은 정식 프로젝트 요구의 선도자격인 것이다. 프로젝트 차원은 프로젝트 자체 평가, 프로젝트 비교, 구조와 기술 선택 등에 사용된다.

다음 블록 만들기는 IoT 구조 청사진으로 구성된다. 현존하는 건축 청사진(서비스 기원 건축 같은)에 만들어, 이들은 새로운 IoT 프로젝트에 필요한 건축학적 관점을 더하고 요구되는 다양한 건축학적 관점을 통합시키는 상부구조를 제공한다.

세번째로, IoT 기술 프로필은 IoT 프로젝트에 요구되는 가장 중요한 기술을 확인하고 설명한다. 그들은 IoT 건축 관점이 이들 다른 기술들이 IoT 구조 전반에 들어맞는 곳을 설명하도록 개선하고 기술 선택을 지원하기 위해 프로젝트 차원으로 되돌린다.

마지막으로, IoT 프로젝트 DB는 IoT 사례 연구를 구조적인 방법으로 기록하는 것을 목표로 하는 계획이다. 그것은 여러 프로젝트의 핵심을 포착하고, 비교 가능하게 하며, 각각의 프로젝트로부터 학습하기 위해 프로젝트 차원을 사용한다.

                           Ignite | IoT building blocks
                           

구조적 방법으로 IoT 프로젝트에 관한 정보를 포착하기 위해 Ignite | IoT 방법론은 5~10개의 부차원이 그룹당 달린(대략 총 40 부차원) 다섯 그룹의 IoT 프로젝트 차원을 정의한다. 각 차원에 Ignite | IoT 는 등급을 1에서 4까지 정의하고 각 등급에 정의를 부여한다.

다섯 주요 그룹은 자산과 기기, 통신과 연결성, 백엔드 서비스, 표준과 규정 준수, 프로젝트 환경이다. 다섯 그룹과 관련 차원의 개관은 아래 도표에서 찾아볼 수 있다.

IoT Project Dimensions

각 IoT 프로젝트 차원은 1~4의 등급을 정의한다. 1은 프로젝트 관리자의 시점에서 낮은/단순한 을 가리키고 4는 복잡한/도전적인 을 의미한다. 다른 차원들에서는 질적 정의를 사용해야 하는 반면에 어떤 차원들에서는 여러 등급 수준을 수량화하는 것이 가능하다. 몇몇 예시들이 아래 스크린샷에 제공되어 있다.

                         Project dimension scales
                           

기초적인 생각은 IoT 프로젝트 차원이 프로젝트 자기 평가를 수행하고, 다른 IoT 프로젝트들을 비교하고, 프로젝트에 쓰일 솔루션 건축과 기술을 선택하는데 사용되어야 한다는 것이다.

                      Use cases for project dimensions
                      

프로젝트 자체 평가를 위해, IoT 프로젝트 차원이 들어있는 엑셀 템플릿을 the Ignite | IoT 웹사이트에서 다운로드할 수 있다. 프로젝트 관리자는 이 템플릿을 프로젝트 차원을 질문표처럼 사용할 수 있다. 최종 결과는 입력의 시각화를 제공하는 Kiviat 도표(혹은 “거미 도표”)이다. 이 과정은 프로젝트 관리자들이 그들의 프로젝트의 위험과 과제에 대한 더 나은 이해를 얻는데 도움이 될 것이다.

프로젝트 비교 목적으로 우리는 현재 우리가 프로젝트 차원 템플릿을 사용해 분석한 IoT 프로젝트 데이터베이스를 만들고. 이 데이터베이스는 또한 Ignite | IoT 웹사이트에서도 사용 가능하게 만들어졌다.

기술 선택 단계 지원을 제공하기 위해, 우리의 목표는 각 IoT 기술 프로필을 다양한 IoT 프로젝트 차원의 측면에서 기술의 적합성에 대한 논의를 통해 끝내는 것이다.

이미 전에 계획/개발/가동 부분에서 소개했듯이, Ignite | IoT는 솔루션 건축을 다른 건축학적 관점에서 묘사하는데 사용되는 일련의 아티팩트에 의존한다. 다양한 아티팩트의 개관– 특히 기능적 기술적 디자인에서– 은 아래 도표에서 찾을 수 있다.

Key Ignite | IoT architecture elements

이들 몇몇 아티팩스 종류가 잘 알려진 보통 IT 프로젝트의 표준 아티팩트인 반면, 다른 것들은 IoT 프로젝트에서 쓰기 위해 특별히 개발된 전문화된 아티팩트 종류이다. 특히, Asset Integration Architecture (AIA)은 자산과 기기(“사물”)과 백엔드 간의 관계를 설명하는 것을 돕기 위한 Ignite | IoT 방법론의 일부로 정의된다. 이것이 다음 우리의 초점이 될 것이다.

우리는 이미 서론에서 Asset Integration Architecture (AIA)에 대한 높은 수준의 개관을 제공했다. Enterprise IoT 맥락에서 AIA의 기초적인 발상은 대부분의 솔루션이 기업 어플리케이션이 제공하는 백엔드 서비스가 있는 연결 자산을 포함한다. 우리의 정의에 따르면, 자산은 차량, 기계, 건물 같은 기업에 대한 보통 주된 경제적 관심인 독립체이다. 자산에서, 우리는 다양한 종류의 기기, 센서, 반응기(창문을 열기 위한 전기모터) 등을 발견한다. 보통, 이들 기기는 또한 다른 속도로 모터를 작동시키는 것 같은 일종의 내장 전력 관리와 기기 통제를 가지고 있다. 많은 자산들은 또한 다양한 작업을 위한 여러 내장 컴퓨터 시스템을 가지고 있다. 예를 들면, 현대의 자동차는 50에서 80사이의 ECU(엔진 통제 유닛)들과, 동력 전달 장치(엔진, 트랜스미션, 구동 축, 차동 장치 등)를 관리하기 위한 유사하고 전문화된 마이크로 컨트롤러를 가지고 있다. 이것이 우리가 “자산 사업 논리”라고 부르는 것이다.

Enterprise IoT 솔루션에서, 한 전형적인 과제는 고정된 모바일 자산의 큰 무리를 관리하는 것이다. 이것은 보통 자산과 기업 사이에 논리적인 연결을 만들어내는 전문화된 단계를 사용하여 달성된다. 우리는 이것을 IoT 클라우드나 M2M 단계라고 부른다. 이 단계는 보통 게이트웨이와 소프트웨어 에이전트를 배치한다. 게이트웨이는 한편으로는 다른 자산 하드웨어 부품을 물리적으로 연결시킬 수 있고 모바일 혹은 위성 통신을 통해 기업 백엔드와의 원격 연결을 가능하게 할 수 있다. 소프트웨어 에이전트는 소프트웨어 기반 지역 통합 작업을 수행한다. 종종, 에이전트는 다양한 커넥티드 외래 기기들을 담아내는 지역 물체(“기기 프록시 물체”라고 알려진)를 만들어내며 그리하여 백엔드와 함께 한 외래 원격 인터페이스를 제공한다. 에이전트는 또한 사건 관리, 지역 사건 관리, 보안, 지역 소프트웨어 라이프사이클 관리 같은 추가적인 기능들을 제공한다.

대응되는 것은 기업 측의 IoT나 M2M 백엔드이다. IoT/M2M 백엔드는 일반적으로 기기 상태 정보와 사견 역사를 포함하는 원격 자산과 기기에 대한 정보를 관리하기 위해 데이터베이스를 시행한다. 이 자산 저장소는 IoT/M2M 백엔드의 중앙 기능이며 보통 사건 관리나 흐름 처리, 관리와 보안 확인, 특정 자산 지불 기능, 원격 소프트웨어 분배와 결합된다.

게다가, IoT/M2M 백엔드는 다른 종류의 미들웨어 기술을 ERP (Enterprise Resource Planning), CRM (Customer Relation Management), PLM (Product Lifecycle Management)같은 현존하는 백엔드 어플리케이션들을 통합시키기 위해 사용한다.

중요한 건축학적 결정은 새로운 백엔드 어플리케이션 논리가 IoT/M2M 백엔드나 현존 백엔드 어플리케이션 중 어느 것에 시행되어야 하는가 이다. 뒤에서, “IOT 기술 프로필” 부분에서 우리는 BPM (Business Process Management)이 양단간 IoT 과정을 더 투명하게 만들기 위한(“IoT 기술 프로필” 부분의 “미들웨어”를 보라) IoT/M2M 백엔드와 기업 어플리케이션 사이의 통합 층으로서 시행될 수 있는 접근법을 제안할 것이다.

                        Asset Integration Architecture
                        

AIA의 한 중요한 이익은 그것이 다양한 산업에서 발견될 수 있는 고도로 다양한 많은 접근법에 대한 구조적 청사진을 제공한다는 점이다. 아래의 도표는 어떻게 AIA 지도가 다양한 산업 전문 접근법에 관한 지도를 그리는지에 대한 개관을 제공한다.

AIA mapped to different industries

예를 들어, 자동차 산업에서는, 당신은 여러, 고도로 전문화된 EUC들이 동력 전달 장치에 분배된 것에서 건축학적 접근법을 보통 발견할 것이다. VCU (Vehicle Control Unit) 는 헤드 유닛으로 작용하고 엔터테인먼트 시스템 같은 다른 시스템들을 위한 중앙 통합 포인트를 제공한다. ECU와 원격 통제 TCU(Telematics Control Unit)이 대부분의 자동차에서는 명쾌하게 분리되어있기 때문에, 우리는 우리의 AIA의 게이트웨이 기능에 TCU 지도를 그렸다. TCU 사용 샘플은 백엔드에서의 차량 관리 솔루션이 될 것이다.

스마트 가정 분야라는 다른 예시를 들어보자. 블루투스, Z-WAVE, EnOcean, 와이파이를 온도 조절 장치나 창문 통제 장치 같은 다양한 지역 접속점에 연결하기 위해 사용할 수 있는 단일 기기에서 게이트웨이 기능을 더 발전된 지역 사업 논리와 결합시키는 중앙 스마트 가정 컨트롤러를 찾을 수 있는 것은 보통이다.

AIA에 쉽게 지도화될 수 있는 다른 사례는 제조업이다. 제조 부문에서, 예를 들어, 공장 제조 라인을 통제하기 위해, 당신은 산업 전기기계 과정을 통제하고 자동화하는데 사용되는 마이크로컴퓨터에 전문화된 프로그램 가능한 논리 컨트롤러(PLCs)를 일반적으로 발견할 수 있다. 그러므로 PLC는 기계에 배치되거나 밀접한 자산 논리일 것이다. SCADA 시스템(Supervisory Control and Data Acquisition)은 원격지시 기술을 원격으로 PLC들의 네트워크를 관리와 중앙 데이터 습득 서버를 백엔드에 제공하는 것을 개선시킨다.

우리가 볼 수 있듯이, Ignite | IoT 방법론에 의해 정의된 자산 통합 건축은 산업 전문 표준에 무관하게 통합 관점에 도움이 된다. 우리는 그것이 어떻게 사용되는지 아래에서 볼 것이다.

엄밀히 말하면, AIA는 그 자체로는 건축이 아니라 오히려 IoT 건축 패턴이 관찰될 수 있는 건축학의 렌즈이다. 견고한 IoT 건축 패턴을 위한 몇몇 예시가 아래 도표에 나타나있다.

                           AIA-based architecture patterns

오른쪽에서, 우리는 모바일 폰의 사례처럼 단순한 패턴인 기기 자체가 직접 백엔드에 연결되는 “Device2Backend”를 볼 수 있다. 그 다음에, “Peer2Peer” (혹은 “Device2Device”)가 기기가 각자와 직접 상호작용하는 패턴을 묘사한다. 다음, Next, “Local Hub” 패턴은 여러 기기의 스마트 가정 컨트롤러 같은 중앙 지역 허브를 통한 연결성을 묘사한다. “M2M” 건축 패턴은 중앙 백엔드에 연결된 여러 자산의 더 위계적인 관리를 묘사한다. 우리의 M2M의 정의와 일치하여, 이 종류의 솔루션은 원격 상태 감시(RCM) 같은 어플리케이션으로 한정되고 발전된 서비스를 제공하지 않는다. 그런 서비스들은 “Enterprise IoT” 건축 패턴에 추가된다.

서론에서 논해졌듯이, 많은 IoT 솔루션들은 더 자족적인 솔루션들을 시작할 것이다. 혹은 우리가 그들을 사물서브넷(SoTs)라고 부를 것이다. 차량 관리와 에너지 관리 솔루션 같은 다양한 SoTs를 통합하기 위해, 아래 도표에 묘사된 건축 옵션을 이해하는 것이 중요하다.

                            Cross-domain integration options
                            

원칙적으로, 통합은 AIA의 어떤 층에서든 일어날 수 있다. 기기 수준에서, 통합은 블루투스 같은 어떤 종류의(보통 무선) 근거리장 통신 종류에서든 일어날 수 있다. 다양한 자산 마이크로컴퓨터 사이에서, 지역 버스 시스템은 통합에 사용될 수 있다. 게이트웨이는 또한 Car2Car 통합 시나리오 종류처럼 각자와 직접적으로 상호작용할 수도 있다. wot.io 같은 전문화된 통합 미들웨어 공급자는 여러 다양한 IoT/M2M 백엔드 플랫폼을 통합시킬 수 있다. 대신, 통합은 백엔드의 어플리케이션 수준에서 실제로 일어날 수 있다 –백엔드를 각자와 통합시키든(그리고 그렇다, 이는 EDI나 Electronic Data Interchange가 가까운 미래에는 사라지지 않으리라는 뜻이다) 혹은 기기들이 다른 백엔드(예를 들면, 클라우드 기반 스마트 가정 종류의 통합)와 상호작용해서 일어나든 상관없다.

“IoT 기술 프로필” 부분은 IoT 솔루션에 종종 사용되는 다양한 기술들을 볼 것이다. 우리가 확인한 기술 프로필은 기기, M2M 하드웨어와 소프트웨어, M2M 백엔드 통신, 일반 미들웨어, 사용자 상호작용(웹, 모바일, 인간-기계 상호작용, 혹은 HMI), 보안, 우리가 플랫폼과 실시가능성이라고 용어를 만든 것을 포함하는 일곱 그룹으로 무리를 이루었다.

                            Technology profiles
                            

우리의 목표는 주요 기술들과 어떻게 그들이 Ignite | IoT 방법론에 묘사된 다른 개념들과 연관되는가에 대한 개관을 제공하는 것이다. 이는 프로젝트 관리자, 솔루션 설계자에게 다양한 기술과 프로젝트 프로필에 따라 언제 그들을 사용해야 하고 언제 사용하지 말아야 하는가에 대한 더 나은 이해의 개관을 제공하기 위해서이다. 우리는 아래 도표에 나타난 템플릿을 따르려고 시도했다. 하지만 실제로는, 그것은 정확히 같은 템플릿을 사용해 모든 기술 프로필을 설명하는 것이 불가능하다는 것을 증명했다. 기술들이 단순히 너무 다양하기 때문이다. 그럼에도, 요지는 어떻게 특정 프로젝트의 프로젝트 차원이 기술이 잘 들어맞을지에 대해 보여줄 수 있을지를 논하기에 앞서서, 기술, 근원적인 기술 건축, 어떻게 AIA에 들어맞는가에 대한 고수준의 개관을 제공하려는 것이다.

                        Technology profile template
                        

이 부분은 지역 및 백엔드 통합을 가능하게 하는 자산 하드웨어를 IoT 게이트웨이와 관련 개념을 통해 다룬다. 이것이 널리 받아들여지는 표준이 거의 없는 너무 광대한 분야이기 때문에, 우리는 우선 아래의 AIA 그래픽에 나와있는 두 공통 시나리오를 정하려고 시도했다. 공동 자산 통합 위상은 포함한다:

• IoT 적용: 보안카메라나 지적 전동 공구(Part III를 보라)같은 IP 가능, 지능적, 자족적인 적용. IoT 적용의 이들 종류는 어떤 IP 네트워크로든 직접, 일반적으로 전문화된 외부 게이트웨이를 통하지 않고 통합될 수 있다.

• 스마트폰&웨어러블(이 사례에서는 자산이 아니라 사람에게 “배치된”): 지역 처리 능력과 주변의 웨어러블 기기의 네트워크에 대한 연결성에 더해 이동통신 사업자를 통한 백엔드 연결성을 제공하는 스마트폰. 이는 때로 WPAN(Wireless Personal Area Network)라고 지칭된다.

• 산업&가정 게이트웨이: 이것은 백엔드에 무선의, 혹은 고정선의 연결성 중 하나를 준다. 그들은 또한 지역 통합 논리(표지/어댑터)와 지역 기기기에의 무선, 혹은 유선 연결성을 제공한다. 지역 기기들은 가정 적용(스마트 가정 게이트웨이의 경우)이나 센서(센서 네트워크의 경우)가 될 수 있다.

• 포그 컴퓨팅(Cisco가 만든 용어): 이는 게이트웨이가 막대한 지역 저장소와 컴퓨팅 능력을 추가하는 기본 게이트웨이 개념의 확장이다.

                       IoT gateways and related concepts
                       

많은 M2M과 IoT 솔루션은 게이트웨이에 의존한다. 게이트웨이는 일반적으로 자산(최소한 우리의 Enterprise IoT 맥락에서는)에 배치되거나 밀접한 전문화된 컴퓨터이다. 게이트웨이는 다양한 기기들, 인터넷, 기업 네트워크에 연결성을 제공한다. 게다가, 게이트웨이는 보통 간단한 경유 논리와 더 복잡한 데이터 수집과 필터링에서 고도로 복잡한 자동화, 분석, 솔루션에 따른 적용 논리까지 지역 논리를 작동시킨다.

M2M/IoT 게이트웨이 중심 건축과 함께 일하는 것은 많은 이점을 갖는다:

• 다양하고 이질적인 기기들이 프로토콜 지도화와 지역 연결성을 위한 게이트웨이를 사용해 더 쉽게 통합될 수 있다 • 게이트웨이는 추상화를 제공하여 더 의미상의 풍부한 적용을 가능하게 한다 • 지역 사업 논리의 실행은 실시간 행동과 반응 시간의 감소를 가능하게 한다 • 게이트웨이는 안정성을 보장하는 수준의 자율화 시행을 돕는다. 예를 들자면 네트워크 문제 사건에서처럼 말이다. • 지역 데이터 분석과 필터링은 네트워크 트래픽을 줄이는 것을 돕는다 • 게이트웨이는 전반적인 솔루션 보안을 향상시키는 지역 보안 솔루션을 배치할 수 있다 • 게이트웨이는 업계에서 지속적인 기업 정책을 보장할 수 있다 • 내장 하드웨어 사업 논리에서 게이트웨이 기능의 개발은 개별 라이프사이클을 가능하게 한다

오늘날 사용되는 많은 다양한 종류의 M2M/IoT 게이트웨이가 있다. 소비자 게이트웨이는 가정 에너지 관리에 더해 가정 자동화와 보안에 사용된다. 전문화된 상업 게이트웨이는 넓은 범위의 교통, 커넥티드 차량, 제조, 에너지를 포함하는 수직들에 이용된다. Wyconn의 CEO인 Adi Reschenhofer는 말한다: “대부분의 M2M/IoT 게이트웨이는 백엔드 연결과 지역 기기, 지역 컴퓨터, 저장 용량의 통합을 위한 무선이나 유선의 연결성 같은 공통 요소를 공유한다. 우리의 M2M/IOT 게이트웨이 매트릭스[see figure below]는 대부분의 일반적인 게이트웨이 종류와 그 주요 요소를 제공한다 .”