loT 솔루션에 대해 이야기할 때 프로세스 관리는 아마 첫 번째로 언급되는 솔루션은 아닐 수도 있다. 이것은 많은 loT 프로젝트가 처음에는 자산을 얻고 연결된 장치들을 얻는데 어려움을 겪고 그리고 나서 백엔드에 기본적인 서비스들을 구축하기 때문일 것이다. 또한 이번 장에서 의논된 바와 같이 많은 프로젝트들은 국내로 들어오는 사건 흐름을 분석하고 관리하는데 혹은 기본적인 분석을 형성하는데 초점을 맞출 것이다. 하지만 우선 초기의 loT 해결 기능이 갖춰지고 연결 장치와 유입되는 데이터 측면에서 시스템이 규모를 확장한다면, 프로세스의 효율성은 결국 아주 중요한 주제가 될 것이다. loT 솔루션에 관해, 장치들과 자산으로부터 초래된 개인적인 사건들, 복합적이고 간접적으로 연관된 사건 (이전 장의 Complex Event Processing 참고)들을 가리키는 더욱 진보된 분석에 의한 결과에 의해 많은 사업 프로세스는 촉진될 것이다.

예를 들어, 예측 보전에 대해 생각해보자. 논의된 바와 같이 Rexroth 사례 연구에서 정교한 기계 학습 알고리즘은 기계 고장이 임박한 사실을 나타내는 상황을 구별할 수 있도록 데이터 센서를 적용할 수 있다. 당신은 말 그대로 센서 네트워크 전문가와 데이터 과학자들이 이러한 유발점을 어떻게 확인할 수 있는지 몇 주간 머리를 맞대고 고민하는지 확인할 수 있을 것이다. 그러나 다음은 무엇일까? 유압식의 요소인 액체에서의 문제로 인해 ACME 광산의 컨베이어 벨트에서 87.25%의 확률로 다음 주의 월요일부터 수요일까지 고장이 발생할 것이라는 정보로 당신은 무엇을 할 수 있는가? 그리고 이러한 정보의 형태가 당신의 기계요소들을 사용하는 수만의 고객들에게 한 주에 수백 번 들어간다면 당신은 무엇을 할 것인가? 이것이 사업 프로세스 관리 (BPM)가 도입된 정확한 배경이며 이는 이러한 요구 사항들이 효과적으로 진행되며 현장 서비스가 가능할 뿐 아니라 활용될 수 있도록 보장하는데 도움을 준다고 할 수 있다.

또 다른 예를 한번 들어보자. eCall 서비스는 우리가 이미 많이 다뤄본 부분이다. 그렇다. 처음 프로젝트가 초점을 맞춘 부분은 정확하게 잠재적인 고장 상황을 발견하고 또한 이런 정보를 처리할 수 있도록 콜 센터에 보내는 것이었다. 그리고 이것은 적어도 콜 센터 매니저의 관점에서는 정확히 BPM이 시작한 부분이다. 그들은 두 가지에 초점을 맞추었다: 첫째로 적절한 프로세스 실행. 이것은 조난 요청을 분류화하고 적합한 언어 기술과 함께 이를 콜 센터에 전송하는 것을 의미한다. 두 번째로 콜 센터 활용. 오늘날 대부분의 콜 센터는 다양한 서비스를 지원한다. 효율적인 콜-전송 프로세스는 비단 SLAs에 대한 보장뿐만 아니라 수익성을 보장하기 위해서도 매우 중요해졌다.

예를 들어, 수십만의 네트워크 요소와 수백만의 고객들을 기반에 둔 큰 커뮤니케이션 네트워크를 설립하고 운영하고 있는 거대한 통신회사를 생각해보자. 통신회사를 운영하기 위한 TM Forum의 청사진인 eTom은 네트워크 관리에서부터 판매, 생산 활성화 그리고 고객 서비스 요청과 같은 고객 관련 프로세스까지 수백 가지의 비판적인 사업 프로세스를 구분할 것이다. 결국 loT는 그리 달라지지 않을 것이다. 따라서 BPM과 loT에 관해 우리 자신에게 질문해야 되는 흥미로운 질문들은 다음과 같다.

• 프로세스 자동화 관점에서 첫째로 다루어져야 할 loT 솔루션 상의 가장 비판적 프로세스를 우리는 어떻게 구분할 수 있을까?
• 자동화는 얼마에 가능해질 것인가(혹은 바람직할 것인가)?
• 언제 프로세스 자동화를 위해 BPM 툴을 사용해야 하는가? 또한 언제 하드 코드 사업 논리와 같은 다른 접근법들을 사용해야 하는가?
• 무엇이 이러한 프로세스의 본질인가? 예를 들어 조직화된 것, 조직화되지 않은 것 등
• 장치에 대한 소프트웨어 프로비져닝과 관리는 BPM 프로세스인가 아니면 어플리케이션 특징인가?
• 어떤 종류의 툴이 사용돼야 하는가? BPM 엔진, 작업 흐름 관리 툴, Jira와 같은 공동 작업 툴?
• 나의 loT 어플리케이션 플랫폼이 내장된 BPM 엔진을 가지고 있다면 이는 이점인가?
• 기술적인 통합은 어떤 형태를 띠는가 (Device2Process 그리고 Process2Device)?

이러한 질문들과 이에 대한 잠재적인 해답에 대해 좀 더 잘 이해하기 위해서 어떻게 프로세스 관리가 잠재적으로 loT 솔루션에 맞춰질 수 있는지 좀 더 자세히 살펴보자. 아래의 수치는 이전 장 (데이터 관리)에서의 AIA에 기반을 둔 AIA이다. 이는 결국 가장 중요한 것은 프로세스는 데이터, 사건들, 그리고 분석의 결과에 기반을 두어 작동돼야 하기 때문이다.

아래에 있는 예시에서, 우리는 한편으로는 M2M/loT 어플리케이션 플랫폼 (다음 장 참조) 또 다른 한편으로는 현존하는 기업 어플리케이션 시스템 (ERP, CRM, PLM등) 사이의 BPM/작업흐름/사례 관리 요소를 배치하였다. 우리가 Device2Process와 Process2Device라고 부르는 패턴은 자산과 장치로부터 나온 투입물에 기반을 둔 새로운 프로세스를 시작하는데 책임이 있다. 똑같은 패턴은 만약 잠재적으로 프로세스 흐름을 바꿔야 하는 장치로부터 나온 연관된 사건들이 출현한다면 현존하는 프로세스의 예를 신호화할 책임도 있다. 이와 유사하게 프로세스는 분석 엔진의 결과에 의해 시작될 수도 있다. 이러한 사용 사례는 예측 분석 알고리즘이 기계 고장이 잘 발생하게 된다는 결론에 도달하고 이러한 상황을 다루는 고객 서비스를 가질 수 있는 프로세스를 시작하는 예측 보전이 될 수도 있을 것이다.

BPM, workflow, and case management in the context of the IoT

우리가 BPM, 작업 흐름, 사례 관리를 구분 짓고 있다는 사실을 주목해보자. 이것들은 복잡한 해결방안들에서 보통 다른 보조 프로세스 혹은 매우 다른 특징들을 가지고 있는 프로세스 부분이 있다는 사실을 다루기 위해 오랫동안 개발된 세 가지 다른 개념들이다. BPM은 ERP, CRM, PLM등과 같이 다수의 후방 시스템의 조직화를 포함하는 아주 강력한 프로세스 자동화로 여겨진다. 작업 흐름 시스템은 인간 작업 흐름에 좀 더 초점을 맞추고 프로세스 자동화에는 덜 초점을 맞춘다. 마지막으로 사례 연구는 유연한 작업 흐름 관리와 같은 데이터 중심적 (“사례 폴더”) 관점을 더해주고 있다.

만약 당신이 토론의 도입부에서 다루었던 Distributed Assets Lifecycle 상의 loT의 영향력에 대해서 다시 생각해본다면, 다른 보조 프로세스의 본질을 이해하고 그들을 지원하기 위한 올바른 프로세스 관리 개념을 선택하는 것은 명백히 중요할 것이다. 예를 들어 loT 제품의 활성화는 BPM에 기반을 두어 이행될 수 있는 전형적인 고도로 자동화된 프로세스이다. 서비스 프로세스는 보통 많은 인간 간의 상호작용을 필요로 한다. 따라서 그들은 작업 흐름 관리에 의존할 것이다. 몇 가지 상황에서는 사례 관리는 지원 서비스의 흥미로운 부분이 될 수 있다. 이는 사례 관리가 관련된 데이터와 사례에 속한 맥락 정보를 수집하는 데에 매우 유용하기 때문이다. 예를 들어, 서비스 기술자는 고객 역사자료에 대한 세부적인 정보와 특정 제품에 대한 묘사를 제공하는 것뿐만 아니라 어떤 지원 운송수단과 어떤 지원 툴을 그들이 사용해야 하는지, 어떤 시간에 그들이 고객을 방문해야 하는지까지도 알려주는 정보 패키지를 얻을 수 있을 것이다.

                         Example of complex process
                         

마지막으로 프로세스와 사건들 사이의 지도 제작은 꽤 복잡할 수도 있고 많은 유연성을 필요로 할 수 있다. 산업상의 컨베이어 벨트를 포함하는 시나리오를 기반으로 하는 위의 예를 한번 봐보자. 이는 이전 데이터 관리 장에서 확인한 Bosch Rexroth에서 제공된 사용 사례와 유사하다. 컨베이어는 백엔드에 기계 학습 접근법을 지원하는 센서를 구비하고 있다. 하나의 주요 구성 요소에 문제가 있다는 분석 엔진 신호와 이러한 부분이 2-3주 안에 고장 날 것을 암시하는 예상을 추정해보자 (1). 콜 센터 대리인이 고객에게 접촉하는 것과 다음 2-3주 내에 예약을 잡는 등의 일을 만들어내는 프로세스 (혹은 사례, 혹은 작업 흐름)는 착수돼야 한다 (2). 이제 고객 장소에 대한 상황이 더 악화된다고 추정해보자: 우리의 CEP (Complex Event Processing) 요소는 요컨대 예측된 것보다 훨씬 상황이 빠르게 악화되었다는 상황을 의미하는 일련의 사건들과 연관성이 있다 (3). 내부적인 규칙은 이러한 상황에 기반을 두어 컨베이어 벨트가 더 이상의 손상을 피하기 위해 즉시 중단될 것임을 결정한다 (4). 프로세스는 이제 반드시 콜 센터 대리인에게 비상조치에 대해 동의하기 위해 고객들에게 긴급하게 다시 연락하도록 충고해야만 한다 (5).

이러한 시나리오는 매우 유연한 방식의 프로세스를 다룰 수 있는 loT 환경이 얼마나 중요해질 것인지 보여준다. 이것을 위한 한가지 좋은 방안은 Adaptive Case Management (ACM)이라는 사례 관리의 가장 유연한 버전을 사용하는 것이다.

아래 항목에서 우리는 Opitz Consulting에서 나온 Torsten Winterberg 씨와 이 주제에 대해 이야기를 나눠 볼 것이다. Torsten 씨는 이 책의 선임 격인 Enterprise BPM에 기반을 둔 BPM 방법론을 개발하고 유지하는 Enterprise BPM Alliance (www.enterprise-bpm.org)의 매우 활동적인 구성원이다.

Dirk Slama: Torsten 씨, loT 세계에 프로세스 관리를 적용하는 것이 왜 중요한지 저희에게 설명해 주실 수 있으십니까?

Torsten Winterberg: 효과적인 프로세스 관리는 당신이 loT 프로젝트에 대해 생각해 볼 때 처음으로 생각나는 것은 아닐지도 모릅니다. 사실, 수많은 Aris 프로세스 분석가와 당신의 Arduino 전문가들을 한 방에 같이 놓는다는 것은 좋은 아이디어가 아닐 수 있을 것입니다. 하지만 저는 후방 프로세스의 진화와 큰 통신회사들의 시스템으로부터 배울 수 있는 것이 있다는 것을 믿습니다. 그들은 지난 20여 년간 마지막 고객들이 사용한 수만의 원격 장치들을 다루는 방법을 학습해왔습니다. 그들의 사업 규모를 고려해 볼 때, 그들은 차라리 일찌감치 프로세스의 효율성을 검토할 수밖에 없었습니다. 이것은 판매와 상품 배열부터 상품 활성화 고객 서비스 프로세스에 이르기까지 매우 다양한 프로세스의 종류들을 포함합니다. 바로 지금, 대부분의 loT 계획은 실제로 통합 장치와 기본 서비스 기능을 이행하는 것과 같은 기본적인 문제 해결에 초점을 맞추고 있습니다. 그러나 이러한 계획들이 규모를 키워 가면 갈수록, 그들은 똑같은 문제에 직면할 것입니다. 그들의 관련 마지막 고객들뿐만 아니라 현장의 수많은 장치들을 관리하는 것은 프리 필터링 사건들과 다른 정보들의 효과적인 방법을 찾는다는 것을 의미합니다. 이것은 자동화된 의사 결정을 도와 사업 규칙을 효율적으로 사용하고 단지 자동화될 수 없는 그러한 문제들이 인간 지원 직원에 도달함을 확신하기 위함이라고 할 수 있습니다.

Dirk Slama: BPM 사물의 측면과 장치 세계를 연결하는 가장 쉬운 방법은 무엇일까요?

Torsten Winterberg: loT 세계에서 자동화된 프로세스로부터 장점을 얻기 가장 쉬운 방법은 “흥미로운 시나리오”를 발견해내고 그러한 시나리오를 다루기 위한 프로세스를 직접적으로 적용하는 것입니다. 예를 들어 기온에 민감한 상품들이 저장되어 있는 몇몇의 창고들을 생각해 봅시다. 만약 기온 장치가 한계점을 초과한 사실을 발견한다면 이는 백엔드에 그 문제를 처리할 수 있는 프로세스를 유발할 수 있을 것입니다. 이러한 프로세스는 몇 가지의 사전 정의된 수단을 적용하는 방법으로 솔루션을 찾으려고 할 수 있습니다. 그것들이 실패한다면 사람들은 그 문제에 대해 살펴봐야 된다는 사실을 눈치챌 수 있을 것입니다. 이러한 과정이 훨씬 더 좋은 또한 훨씬 효율적인 작업 환경으로 이끌 것입니다; 고용자들은 아마 자동화된 문자 메시지 혹은 발생 전화와 같은 수단으로 편차에 대해 반응하면 될 것입니다.

Dirk Slama: 그렇군요. 매우 간단한 예시네요. 사실 좀 더 복잡합니다. 프로세스는 사례는 장치로부터 나오는 여러 가지 다른 들어오는 신호에 대해 반응해야만 할지도 모릅니다. Torsten 씨는 BPMN에 대한 이러한 문제점을 어떻게 해결할 수 있을까요?

Torsten Winterberg: 글쎄요. BPMN 엔진은 신호들을 다룰 수 있는 꽤나 괜찮은 내장된 메커니즘을 가지고 있습니다. 따라서 프로세스 사례는 많은 들어오는 사건들에 대해 대응할 수 있을 것입니다. 그러나 물론 문제를 다루는 이러한 방식이 BPMN의 전문 분야는 아닙니다. 프로세스 모델은 다른 사건들의 복잡한 사업 규칙을 통제하기 어렵게 만드는 많은 사건을 다루는 상징물들과 함께 오염되는 경향을 보이고 있습니다. 환경의 변화는 언제나 BPMN 모델의 변화를 필요로 하게 만들 것입니다. 요약해보면 이러한 시나리오의 복잡성과 환경의 변화에 대한 부족한 적응력은 BPMN 패러다임을 지나치게 긴장시키게 만들 것입니다. 그러므로 ACM이라고 불리는 BPM 규율을 사용하는 것을 저희는 추천합니다.

Dirk Slama: ACM의 의미에 대해서 좀 더 설명해주실 수 있으신가요?

Torsten Winterberg: 간략하게 ACM은 Adaptive Case Management을 의미합니다. 그리고 프로세스 모델이 너무 복잡해졌을 때, 당신이 단순히 간단한 해피 패스 모델을 가지고 있지 않을 때 혹은 당신의 좋은 BPMN 모델을 오염시킬 수 있는 많은 수의 예외 “코드”를 다룰 때 BPMN의 매우 흥미로운 대책일 것입니다. ACM은 BPMN 활동 사이의 이행에 대한 요구를 제거하고 일련의 의사 결정 규칙에 대한 이행을 대체합니다. ACM은 귀납적입니다. 예를 들어 자동차 안에 있는 네비게이션 시스템처럼 목표는 확실하나 길(프로세스 그 자체)는 불확실하고 단계적 확대들로 가득 차 있습니다. 반면 BPMN은 사전 정의된 길과 함께 있는 철도 시스템처럼 보일 수 있습니다. 만약 당신이 지름길을 원하거나 새로운 길을 원한다면 당신은 현존하는 길이나 미리 지어진 새로운 길을 사용해야 할 것입니다. IT 세계에서 “구조화되지 않은 프로세스”란 ACM의 감각이라 할 수 있을 것입니다.

Dirk Slama: 그렇다면 ACM은 구조화되지 않은 프로세스에 사용될 수 있는 규율이라고 할 수 있군요. 그러면 이것이 loT에 대해서는 어떻게 도움을 줄 수 있을까요?

Torsten Winterberg: “구조화되지 않은”이라는 용어는 보통 뭔가 혼돈 상태를 의미합니다. 하지만 여기서는 아니죠. 많은 프로세스들은 목표 중심적이거나 사례 중심적입니다. 그리고 지식 노동자들이 이러한 목표를 달성하기 위해 선택한 길은 보통 엄격하게 정의되지 않고 그들의 정보의 평가를 고려하는 것입니다. 예를 들어 의료 사례를 생각해봅시다: 환자는 병원에 들어올 것이고 몇몇의 장소에서 다양한 사람들의 전문지식에 의해 이동될 것입니다. 프로세스 관점으로 보면 환자는 병원에 들어오고 몇몇 구조화되지 않은 것들이 발생하며 최종 목표는 환자가 다시 병원을 떠나는 것이며 (물론 건강하게) 마지막으로 청구서가 보내지는 것일 겁니다.

loT의 응급상황과 함께, 이러한 사례의 종류들도 진화할 것입니다. 원격 상태 모니터링은 환자 상태와 관련된 실시간 사건들과 같은 임상 사례들에 추가적인 투입물을 제공할 수 있을 것입니다. 사용 기반 보험 (UBI)은 보험 회사들이 미래에 보험 관련 사례들을 어떻게 다룰지에 대해 영향력을 발휘할 것입니다.

ACM에서 당신은 늘 그렇듯이 지식 노동자들이 “사례”를 살펴 보기 위해 사용한 당신의 포탈에 계기판을 가지고 있습니다. UI는 지식 기반 노동자들에 의해 실행될 수 있는 근본적인 지식 기반의 현재 상태에 의해 좌우되는 그러한 활동들을 강조하고 있습니다. 통합 플랫폼과 함께 하는 공동 작업에 있는 ACM 엔진은 다른 장치의 모든 종류의 들어오는 사건들을 쉽게 수집할 수 있습니다. 이와 같이 적응 가능한 변화를 의미하면서 이러한 사건들은 근본적인 지식 기반을 바꿀 수도 있고 바꾸지 못할 수도 있습니다. 따라서 몇몇 신호 사인은 “ 녹색” 혹은 “적색”이 될 수 있으며, 들어오는 사건들에 영향을 주는 사업이 가져야만 하는 것에 따라 몇 가지 종류의 활동들은 가능하거나 불가능할 수 있습니다. 임상 사례에 대한 관계는 간단합니다. 메시지와 함께 각각의 장치들은 임상 기기 또는 다른 가치를 측정하고 의사로부터 적정한 반응을 의미하고 확정하는 임상 실험처럼 보일 수 있습니다.

Dirk Slama: 흥미로운 접근법이네요. 그런데 이러한 접근법이 BPM 세계에서 너무 복잡한 메커니즘을 소개하는 방법이 되지는 않을까요?

Torsten Winterberg: 그럴 수도 아닐 수도 있다고 말씀드려야겠네요! 시스템의 유저에게 ACM은 삶은 훨씬 쉽게 만든다고 할 수 있습니다. 이는 작업의 초점이 사업 사례에 맞춰져 있고 프로세스에서 일하는 사람이 가장 효과적인 방향으로 프로세스를 수행할 수 있는 새로운 자유를 가지고 있기 때문입니다. 다시 한번, 당신이 네비게이션 시스템을 사용하는 방법과 이것을 비교해 보십시오. 목표는 타깃 주소에 접근하는 것이지만 당신은 가능한 최선의 길을 택할 수 있는 자유를 가지고 있습니다. 대부분의 경우에 이는 명령어로 번역된 길로 주어지겠지만 확실하지 않은 환경은 유연한 반응과 길의 변화를 필요로 할지 모릅니다. 이러한 “지식 노동자”측의 사용의 용이성은 ACM 엔진 사례를 설계하는 데 있어서 더 높은 복잡성을 필요로 할 것입니다. 그러나 오늘날의 ACM 엔진들은 사업 규칙 엔진들을 통합하고 있으며 이러한 근본적인 규칙들의 투명성을 통해 더 나아지고 있습니다. 그리고 이러한 사실은 이러한 복잡성이 더 이상 큰 장애물이 아니게 만들었습니다..

Dirk Slama: 우리는 ACM이 Device2Process 솔루션을 위한 매우 귀중한 접근법이라는 것을 배웠습니다. 하지만 그 반대는요? Process2Device와의 연관성도 찾아 볼 수 있을까요

Torsten Winterberg: 사례를 성공적으로 완성하기 위해서, 당신은 아마 사례 데이터 사례 상황 그 자체를 포함하는 바깥 세계를 다루게 될 작업을 수행할지도 모릅니다. 그것들은 대체로 명확하고 안정적이기 때문에 당신은 이러한 작업 뒤에 있는 작은 BPMN 프로세스를 사용할 것입니다. 한가지 예로 피 분석은 명확하지만 피의 가치와 관련하여 나온 결과와 필요한 반응들은 명확하지 않은 것입니다. 따라서 질문은 프로세스 (BPMN에서 실행 가능한)가 위의 예와 같이 당신의 Process2Device로서의 “어떤 것”과 교류하는 것인 가능한 지입니다. 이것이 함축적으로 의미할 수 있는 것은 무엇일까요? 우리는 이것을 밝혀내기 위해 해야 할 일이 여전히 몇 가지 남아 있다는 사실을 생각해 볼 수 있습니다. 물론 프로세스는 경고 가치의 한계점을 조정하는 것과 같은 어떤 것과 상호 교류할 수 있습니다. 그러나 우리는 프로세스가 아마 단순히 사건이나 메시지를 내보낼 것 같다고 생각할 것입니다. 그리고 나서 몇몇 다른 시스템 (loT 클라우드 같은)에 의해 소비되고 결국 개별 장치들과 상호 작용을 할 것이라고 생각할 것입니다. 상황은 앞으로 몇 년간 매우 빠르게 진화할 것이고 따라서 당신의 컴퓨터 시스템의 구성은 적응 가능해야 하기 때문에, 일반적으로 당신은 당신의 프로세스와 장치 세계 사이의 지나치게 가까운 결합을 원하지는 않을 것입니다.

요컨대, 수동으로 자료를 편집하기 위해서 너무 많은 데이터와 복잡성을 갖는 것은 분석하고 반응하는 것이며 목표 중심적이고 사업 프로세스 수행하기 위해 유연한 방법을 갖는 기원은 명확한 보조 작업과 장치들의 통합을 위한 BPMN의 보조 프로세스와 함께 ACM 접근법을 위한 탄탄한 사례들을 만들 것입니다. 우리는 이러한 통합된 접근법이 오늘날 BPM 이행의 많은 결점들을 해결할 수 있기 때문에 매우 기쁩니다. 현재 거기에는 많은 수의 여전히 예측하지 못한 새로운 사업 모델들을 기대하면서 또한 크고 새로운 전문가들이 대중 데이터의 이용 가능성을 통한 기회에 영향력을 발휘할 준비가 되면서 골드러시 분위기가 다분합니다.