국내도서상세

생성형 AI 시대에 생존하라

PI, 제대로 알고 시작하라: 이해와 오해

PI를 하면 일이 편해지나?

영업 활동을 수행하면서 고객을 관리하며 계약을 수주하는 직원으로서는 자신의 영업 활동에 대해 시스템이 알아서 정보를 정리하고 결과 보고나 고객 관리를 자동으로 처리해 주는 시스템을 원한다. 당연히 기존에 하던 업무 방식보다 편리해지는 장점도 있겠지만, PI 관점에서는 영업 활동의 편의성뿐만 아니라 사업 수주를 높이고 계약 성사율을 높이는 프로세스 혁신을 함께 고민해야 한다. 그리고 수주율과 계약을 높이기 위해 시장의 정보를 보다 잘 수집할 수 있는 마켓 인텔리전스(Market Intelligence)와 관련된 프로세스, 새로운 사업 아이템을 발굴하고 제안할 수 있는 신사업 발굴 프로세스까지도 PI의 범위로 새롭게 고려할 수 있다. 이때 관행적으로 업무를 하던 영업 담당자는 기존 업무는 자동화되어 편해질 수 있지만, 신설된 프로세스로 인하여 하지 않던 일을 추가로 할 수도 있다. PI로 인해 일이 줄어들 것으로 생각했는데, 오히려 일이 늘어나는 것이다. 따라서 PI는 편의성 관점의 업무 개선이나 자동화보다는 전략적 관점의 사업 성과를 달성하는 것을 목표로 일한다고 볼 수 있다. 이 때문에 단순히 효율화 관점에서 편리성만을 기준으로 프로세스 혁신을 설명하기는 어렵다.

PI, 더 많은 일을 시키려는 것일까?

남는 것 없는 장사라는 말을 많이 들어 보았다. 대부분 그럴 리가 없다고 생각한다. PI에도 상당한 투자가 수반되는데 무엇이 기업에 남길래 막대한 예산이 PI에 투입되는 것일까. 단순히 일하는 직원들의 업무를 효율적으로 만들기 위해 업무 방식을 정형화하고 표준화하는 것만이 목적일 수는 없다. 회사는 손에 잡히지 않는 모호한 결과를 위해 투자하지 않는다. 업무를 표준화한다는 것은 정의된 업무 방식과 기준에 따라 업무의 시작과 결과가 정량적으로 드러나게 만든다는 것이다. 업무 프로세스가 이렇게 가시적으로 보이게 되면 무엇이 달라질까. 회사는 지속적인 성장을 목표로 움직이는 공동체이다. 따라서 성장을 위해 비용 효과적으로 관리해야 하는 많은 관리 요인이 있다. 계약 성사율, 업무 마감률, 품질 준수율, 안전사고 발생률, 불편 처리율 등 사업을 만들어 내고, 운영/관리하고, 매출과 이익을 달성하기 위해 관리하는 지표들이 있다. PI 이전에는 이러한 지표들에 대해 어떤 상황인지 물어보면, ‘문제가 별로 없다’ 또는 ‘문제가 좀 있다’는 대답을 듣고는 했다. 이슈가 많거나 적은 편이라고 답변하거나, 성과가 좋거나 낮은 편이라고 답변한다. 그러나 PI 이후에는 이러한 항목들이 100% 기준으로 몇 %인지를 정량적으로 알게 된다. ‘일을 잘하는 편이다’ 또는 ‘미흡한 편이다’라고 말하던 것들도 표준화가 되다 보니, 상위 10% 이내인지, 하위 10%에 해당하는지를 알 수 있게 된다. 관리 지표를 기준으로 부서별, 직급별, 직무별, 지역별로 순위화된 정보들이 한눈에 보인다. 이렇게 파악된 정보는 우수한 성과를 만들어 내는 상위 그룹과 하위 그룹을 구분 짓게 만든다. 그리고 상위권의 업무 방식을 참조하여 미진한 그룹을 상향 평준화시키는 방법으로도 활용된다. 상위권, 하위권, 평균권을 기준으로 업무 생산성을 높이고, 각종 리스크를 예방 관리하는 경영 관리의 효과적인 수단으로 활용되는 것이다.

PI 조직을 구성하는 법

1) PM(Project Manager) / 프로젝트 관리자

PM은 프로젝트 관리자로서 프로젝트를 총괄하는 사람이다. 프로젝트 관리자는 고객뿐 아니라 프로젝트 구성원과 끊임없이 소통하면서 PI를 성공시키기 위한 자원이나 정보를 이끌어 내고, PI가 목표 지점까지 잘 도착하도록 프로젝트라는 차량을 운전한다. PMP(Project Management Professional)라는 프로젝트 관리 전문가 국제 자격증 과정에서도 다루어지는 내용이지만, 프로젝트 관리자는 프로젝트의 시작에서 종료까지의 기간 동안 비용, 일정, 범위 등 다양한 영역을 관리하며 프로젝트의 완성을 책임진다. 따라서 프로젝트 관리자 역시 PI 경험을 비롯하여 유사한 업종에서의 프로젝트 수행 경험이나 IT 이력, 평판 등을 신중하게 검토해야 한다. 또한 프로젝트 관리자 후보가 어떤 성격의 사람이며, 어떤 강점이 있는지도 파악해야 한다. 프로젝트 관리자는 프로젝트의 분위기를 좌우하는 사람으로, 프로젝트 관리자의 성격에 따라 구성원들의 분위기가 경직될 수도, 편안해질 수도 있으며, 개인주의적이 될 수도, 자유분방해질 수도 있다. 가급적 고객사의 조직 문화와 맞는 성격이 서로에게 편할 것이다. 또한 사람마다 가진 강점이 다르기에, 어느 한 프로젝트 관리자는 고객과 소통을 잘하고, 어떤 관리자는 일정과 사람 관리에 능숙하고, 다른 관리자는 결단력과 협상력이 뛰어나고, 또 다른 관리자는 기술 전문성을 바탕으로 품질 관리가 노련할 수 있다. 프로젝트의 범위가 넓고, 규모가 큰 대형 프로젝트일수록 모든 분야를 아우르는 사람이면 좋겠지만 그렇지 못한 경우를 대비하여 강점의 우선 순위를 정할 필요가 있다. 프로젝트 관리자의 강점을 살리고, 약점을 보완하기 위한 프로젝트 관리 조직(PMO, PM Office)을 구성하여 프로젝트 관리자가 제 역량을 충분히 발휘할 수 있도록 조직 구성을 할 수 있기 때문이다.

2) PMO(Project Management Office) / 프로젝트 관리 조직/사무국

프로젝트의 규모가 크다면, 프로젝트 관리자 혼자서 프로젝트를 관리할 수 없으므로 프로젝트 관리 조직 또는 프로젝트 관리 사무국이라고 부르는 PMO를 구성하게 된다. 인원이 비용인 만큼 최소한의 인력으로 운영되는데, 프로젝트의 예산 규모에 따라 다르다. 50명 안팎의 인원 규모라면 한두 명의 인원으로 운영되는 편이다. 프로젝트 관리 조직은 프로젝트 일정에 따라 단계별 활동 목록과 체크 리스트를 준비하고, 일정의 지연이나 누락이 없도록 프로젝트의 산출물을 모니터링하고, 프로젝트 내의 이슈와 리스크에 대해 관리자에게 리포팅하고, 프로젝트 관리자의 전달 사항에 대해 프로젝트 구성원에게 공유하는 역할을 수행한다. 프로젝트 규모가 작다면 이 모든 일을 프로젝트 관리자가 직접 수행해야 하지만, 그렇지 않은 경우 프로젝트 관리 조직을 통해 프로젝트 관리 활동을 지원받을 수 있다. 따라서 프로젝트 관리자의 손발로써 합이 잘 맞는 프로젝트 관리 조직을 구성할 때, 관리자는 보다 PI 성과 창출에 집중할 수 있고 우수한 결과물을 낼 수 있다.

3) IM(Integration Manager) / 통합 이슈 관리자

통합 이슈 관리자는 프로젝트 관리 조직 구성원 중 하나로서, 프로세스 간 연결 지점들을 파악하고 통일된 기준에 따라 중복된 내용이나, 이질적인 내용이 없도록 프로세스 간의 교통정리를 하는 역할이다. 프로세스를 연결하거나 통합하는 과정에서 프로세스 담당자들이 다르다 보니, 동일한 내용들이 모든 프로세스에 중복적으로 담기기도 하고, 동일한 기준으로 수행되어야 할 업무들이 프로세스별로 달라지는 경우도 생긴다. 물론 프로세스별 담당자 간에 필요한 협의가 진행되었음에도 누락되는 사항도 생기고, 협의를 진행했지만 동일한 기준을 가지고 표기하지 않아서 비슷한 내용인데 다르게 보이는 경우도 생긴다. 따라서 통합 이슈 관리자는 모든 회의에 참석하면서, 전체 프로세스 관점에서 파트별 개선안들이 협의된 기준에 따라 일관성 있는 결과물로 만들어지도록 조율하는 역할을 수행한다. 표준화된 템플릿이나 샘플 자료를 프로세스 담당자에게 배포하고 누락된 부분의 보완을 요청하면서 전체 관점에서 프로세스 간의 연결과 통합을 매끄럽게 만드는 것이다. 매우 중요한 역할이지만, 모든 프로세스의 진행 상황과 파트별 논의 내용에 대한 이해가 부족하다면 오히려 더 많은 혼란을 가중하는 역할이기도 하다. 프로세스에 맞지 않는 템플릿을 배포한다거나, 이미 작성된 내용인데도 유사한 템플릿의 재작성을 요청할 수 있기 때문이다. 따라서 파트별 논의 사항에 대한 높은 이해와 PI에 대한 노련한 경험치가 담보되지 않은 통합 이슈 관리자라면, 인력 운영 차원에서 오히려 일반적인 프로젝트 지원 인력을 한 명 더 충원하고, 통합 이슈 관리자의 역할은 파트장급에서 겸임하는 것도 방법일 수 있다.

4) QA(Quality Assurance) / 품질 보증 담당자

PI 역시 품질 관리를 위해 업무 단계별로 작성되어야 하는 필수 산출물이 있다. 왜 필수일까. 프로젝트가 성공적으로 끝나고, 아무런 이슈가 없을 때는 이런 산출물들이 형식적인 문서이고, 업무 시간을 많이 소비시키는 문서 작업이라고 생각할 수도 있다. 그러나 일정이 지연되거나, 장애가 터졌을 때, 또 그로 인해 고객이 손해를 보게 된다면, 제일 먼저 들여다보는 것이 이러한 산출물들이다. 품질 관리 체계에 따라 고객과 약속한 업무 범위가 정상적으로 수행되었는지를 확인하기 위해서이다. 장애가 있는 시스템의 설계와 개발이 왜 정상적으로 이루어졌다고 생각했는지를 파악하기 위함이다. 화면 설계서, 테스트 계획서, 테스트 결과서, 설계자나 개발자가 변경됨에 따른 인수인계서, 프로그램 개발 목록과 개발 기준서 등의 다양한 문서들이 품질 관리가 제대로 이행되었는지를 확인하는 대상이 된다.

프로젝트를 진행하는 촉박한 일정 속에서 품질과 관련된 문서 작업들은 종종 우선순위에서 밀리곤 한다. 아무도 보지 않는 형식적인 문서라고 생각하고, 대충 작성하고 싶은 유혹이 생긴다. 자신이 만든 문서가 아니라도, 누군가 설명해 줄 사람이 있을 테고, 굳이 개발 문서가 없어도 ‘개발 코드를 살펴보면 이해하겠지’라는 생각으로 합리화한다. 공동의 작업 규칙을 따르지 않고, 나만의 스타일로 프로그램을 개발해도 당장은 프로그램이 돌아가니 문제가 없다고 생각한다. 그러나 프로젝트에는 다양한 업무 경험과 다양한 개발 성향을 가진 사람들이 들어오고 나간다. 따라서 설계와 개발 역시 정해진 규칙에 따라 만들어야만 시스템 기반의 서비스 품질을 연속성 있게 관리할 수 있다. 따라서 품질 관리를 담당하는 QA 담당자는 단계별 활동들과 산출물들이 약속된 수준으로 나오고 있는지를 점검하고, 미흡한 부분은 합의된 눈높이의 산출물이 나오도록 관리하면서 프로젝트의 모든 단계에 걸친 산출물 수준을 관리한다. 주목받는 역할은 아니지만, QA가 부지런한 프로젝트일수록 프로젝트 이후의 이슈가 최소화 될 가능성이 높다. 다만, 촉박한 프로젝트의 일정상 문서 작업이 본업을 해칠 정도로 과한 것은 문제가 될 수 있다. QA는 품질 관리의 목적에 부합하는 필수 문서들을 최소화시켜 선별하고, 문서 작성이 용이하고 효율적인 방법을 지속적으로 고민해야 한다. 최근에 다양한 협업 툴이 시중에 많은 만큼, 프로젝트의 성격에 적합한 툴을 활용하는 것도 하나의 방법이 될 것이다.

성공하는 PI를 위한 제언 8가지

1. PI 성과와 성공의 잣대

PI는 프로세스 표준화로 인정받지 못한다. 사업적 성과를 내어야만 인정받을 수 있다. 그래서 PI에서 다루는 이슈는 매출 성장, 원가 경쟁력 등 사업적 성과에 미치는 영향도가 높은 사안이어야 한다. PI 이슈로서 발제되는 많은 사안이 있지만, 이슈를 해결했을 때 성과 기여도가 정량적으로 표현될 수 없다면 PI에서 다루기에는 적합하지 않을 수 있다. PI가 프로세스 개선과 업무 편의성 증대에 초점을 맞추기보다는 사업 전략과 사업 모델에 초점을 맞추어야 하는 이유이다. 그렇지 않을 경우, PI는 안팎의 상황에 따라 당위성과 추진력을 쉽게 잃는다.

2. 표준화 이후 지표 관리를 통한 변화 관리

PI는 표준화로 끝나는 것이 아니라 표준화에서부터 시작한다. 표준화 이후에는 지표 관리가 가능해지고, 중점 관리되는 지표는 결국 상향 평준화로 수렴된다. 지표 하위권은 지속적인 모니터링을 통해 개선되고, 상위권은 노하우를 공유해주기 때문이다. 따라서 회사의 변화되는 사업적 상황과 이슈별 우선순위에 따른 지표 항목의 인/아웃 및 모니터링은 변화 관리의 핵심이다.

3. PI, 전문가의 혜안과 함께

PI는 깊이 있는 고민을 할 수 있는 전문가 집단으로 구성되어야만 한다. 업무에 대한 풍부한 경험과 이슈에 대한 깊은 고민을 많이 해본 사람이어야 제대로 된 해결안을 만들 수 있다. 혁신의 폭은 생각하고 상상한 만큼만 구현되기 때문이다. 현재를 뛰어넘을 만한 혁신을 고민할 수 있는 사람들을 모아야지만 제대로 된 PI를 실행할 수 있다.

4. 내부 역량 수준에 따른 PI 추진

PI는 남이 대신 수행할 수 없다. 외부 전문가가 투입되더라도 내부 전문가와의 긴밀한 협업이 요구되는 영역이다. 따라서 회사 내부에 PI를 수행할 인적자원이 충분한지를 냉철히 판단해야 한다. 내부의 역량이 충분하지 않다면 모든 프로세스를 빅뱅 방식으로 추진하기보다는 프로세스를 쪼개어 단계별로 접근하는 방식이 나을 수 있다.

5. 프로세스 혁신은 조직/체계와 연동

프로세스를 바꿀 때는 연관 조직이나 부서의 기능도 함께 변경되어야 한다. 프로세스는 통합되었는데 연관 부서들의 기능이 통합되어 있지 않다면, 현장은 혼란스러울 수밖에 없다. 변화란 어느 한 부분만 바꾼다고 해서 이루어지지 않는다. 변화에 연관된 사람들이 일하는 방식을 전체적으로 다루어야 한다. 따라서 변화된 방식의 프로세스에 따라 부서 간의 역할과 기능에 대한 합의가 선행되어야 한다.

6. 고객의 숨겨진 니즈 발굴

PI는 드러난 이슈뿐 아니라 표출되지 않은 잠재적 이슈까지도 미래 지향적으로 살펴보아야 한다. 특히 고객 관점에서의 페인 포인트를 분석할 때 아직 발현하지 않은 충족되지 않은 니즈(Unmet Needs)까지도 검토해야 한다. 고객은 경험한 현상에 대한 이슈만을 말하지만, 본인들도 모르는 새로운 경험 환경 속에서 잠재되었던 니즈도 중요한 서비스가 되기 때문이다. 그리고 이러한 니즈가 고객 가치 창출을 위한 신규 서비스의 핵심 단서가 될 수 있다. PI는 고객의 숨은 니즈를 발굴할 수 있는 프로세스나 조직 체계를 만드는 것까지도 함께 다루어야 한다.

7. 탑-다운형 마인드 전환

변화 관리의 핵심은 마인드 전환이다. PI를 통한 변화는 항상 저항받게 되어 있다. 하지만 일단 시작한 PI는 끝까지 달릴 수밖에 없다. 이러한 저항감을 최소화하려면 리더를 중심으로 한 탑-다운형 마인드 교육이 필수적이다. PI의 하향식 전개 길목에 서 있는 리더들이 도와준다면 더욱 빠르게 PI는 확산할 수 있다. PI에 대한 리더들의 설득과 이해를 위해 대면 교육과 워크숍 등을 적극적으로 실시하는 이유이다.

8. PI 저항을 최소화하는 매끄러운 연결성

사용자를 불편하게 만드는 UX는 외면받을 수밖에 없다. 변화된 시스템과 프로세스를 따라가기 위한 인위적인 데이터 입력이 많고, 복잡한 프로세스일수록 더욱 그렇다. 업무 수행을 위한 일상의 행동이 데이터화될 수 있게 한다면, 사용자는 변화된 프로세스에 보다 빠르게 적응할 수 있다. 직관성이 높고 매끄럽게 연결되는(Seamless) 내비게이션일수록 시스템에 대한 저항감은 작다. 가능한 본연의 업무를 수행하면서 자연스럽게 필요한 데이터가 시스템으로 전달되는 기술이 필요한 이유이다.

자신에게 맞는 AI 역할은?

AI, 나는 어디로 가야 하나?

기획자는 업무 전문가로 코딩을 할 수 없으나 담당하고 있는 분야에서 전문적인 지식과 경험을 가지고 있다. 오랫동안 카드 업무를 담당하는 경우에는 카드의 비정상 거래의 패턴과 특징을 알고 있다. 자동차 수리를 오랫동안 했다면, 엔진 소리만 들어도 어떤 고장인지를 알 수 있다. 글로벌하게 원자재를 구매하는 경우에는 계절별, 월별, 지역별 가격 추이에서 원자재의 가격 등락의 추이를 확인하여 원자재 구매 시기를 결정한다. 이처럼 코딩을 할 수 없지만, 업무 전문가는 AI 기획자가 될 수 있다. 기획자는 데이터 사이언티스트인 모델 개발자에게 모델 개발에 핵심이 되는 변수(Feature engineering)를 알려준다. 응용 개발자는 웹 시스템과 애플리케이션 개발을 담당하며 코딩에 전문성을 가지고 있다. 모델 개발자는 기획자가 알려준 변수를 가지고 인공지능 알고리즘을 활용해서 예측 모델 개발을 담당하며, 예측 모델을 학습과 테스트하여 예측 정확도를 높여 응용 개발자에게 함수로 전달한다. 응용 개발자는 코딩을 통해 웹 시스템과 애플리케이션을 연결하여 예측할 수 있는 기능을 사용할 수 있게 한다. 그래서 모델 개발자는 ‘Maker’이고, 응용 개발자는 모델 개발자가 제공하는 함수를 받아서 코딩하는 ‘Builder’가 된다. AI 기획자는 모델 개발자에게 업무 흐름의 패턴과 특징을 제공해 주며 모델 개발자는 업무의 패턴과 특징을 가지고 예측 정확도를 높일 수 있는 인공지능 알고리즘을 선택해서 모델을 학습하고 테스트하여 정확도가 높은 예측 모델을 함수(API)로 응용 개발자에게 전달하여 개발하는 흐름을 가진다.

디지털 트랜스포메이션으로 떠나는 여정

DX 역할과 실행 프레임워크를 설계하라

DX의 역할은 5가지로 나눌 수 있다. 첫째, 비즈니스 모델 혁신으로, DX는 기업의 수작업과 오프라인 비즈니스 절차를 디지털 중심으로 전환할 수 있게 지원해야 한다. 이를 위한 전환은 모바일과 사물 인터넷/빅데이터/AI/챗봇/사무 자동화(RPA, Robotics Process Automation)/웹 3.0 등 디지털 기술을 활용하여 이루어진다. 비즈니스 모델 혁신은 기존 비즈니스로부터 새로운 수익 구조를 만들어 내고, 고객 여정으로부터 수집된 데이터 중심 시장과 고객 서비스를 분석하여 신규 비즈니스 모델을 개발한다.

둘째, 고객 경험의 개선이다. DX는 고객 경험을 개선할 기회를 제공하며, 고객은 상품이나 서비스에 대한 정보를 언제 어디서나 쉽게 얻을 수 있고, 온/오프라인에서 편리하고 빠르게 구매와 서비스 지원을 받을 수 있게 하여, 고객 만족도를 높이고 브랜드 충성도를 강화하는 것을 지원한다.

셋째, 비즈니스 프로세스 최적화이다. 디지털 기술은 비즈니스 프로세스를 최적화하여 민첩하고 효율적인 운영을 가능하게 하며, 핵심 성과 지표(KPI, Key Performance Indicator)에 따른 실행과 평가 및 모니터링을 하여 지속적인 비즈니스 프로세스의 최적화를 지원한다. 특히, 재고 관리와 수요 예측, 콜센터나 상품 Q&A와 같은 고객 서비스 등 AI를 활용한 데이터 분석을 통한 프로세스의 최적화는 생산성 향상과 비용 절감을 통해 최종적으로 기업의 경쟁력을 향상시킨다.

넷째, 조직 문화이다. DX는 단순히 기술뿐만 아니라 커뮤니케이션과 조직 문화에도 영향을 미치며, 디지털 기술과 데이터 기반의 의사 결정 절차를 수용하여 적극적으로 참여하고 협력하는 조직 문화를 만들어 낸다. 디지털 기술을 갖춘 직원의 비중이 늘어나고 교육과 훈련을 통해 전사 구성원의 디지털 역량이 향상된다.

마지막 다섯째는 기술 혁신이다. DX는 생성형 AI와 디지털 트윈 메타버스 중심의 전사 프로세스 재편을 통해 업무 자동화와 지능화에 의한 업무 생산성 향상, 지역/시간을 초월한 원격 업무 협력, 지속 가능한 수직/수평적 네트워크 중심의 업무 환경을 지원한다.

디지털 트랜스포메이션 프레임워크(Digital Transformation Framework)는 기업이나 조직이 디지털 기술을 통해 비즈니스 모델과 고객 경험, 조직 문화, 업무 프로세스 등을 근본적으로 개선/혁신하기 위한 체계적이고 구조화된 가이드라인을 제공한다.

DX 프레임워크는 6가지의 요소로 구성할 수 있다. 첫째, 비전(Vision)이다. 조직이 DX를 통해 달성하고자 하는 단계별 목표를 구체적으로 설정하여, 최신 기술을 도입하는 것을 넘어 가치 창출과 문제 해결을 위한 일관된 전사적 목표와 가치를 공유하는 과정이다.

둘째, 전략(Strategy)이다. 비전을 실현하는 데 필요한 단계적인 계획과 방법론을 구체화하며 역할 정의와 자원 분배, 추진 일정, 투자 계획, 예산 집행, 위험 관리 등 다양한 변수를 고려하는 핵심 성과 지표(KPI)의 정의와 평가 프로세스를 포함한다.

셋째, 조직(Organization)이다. DX를 실행할 조직과 역할을 정의하며, 전사적 수준에서 통합과 협업 지원 팀 빌딩(Team Building) 및 기존 조직 구조의 개선과 최적화를 결정하고, DX 커뮤니케이션과 조직 문화를 만든다.

넷째, 프로세스(Process)이다. 기업의 업무 처리와 절차를 디지털화와 표준화, 자동화, 지능화를 기획/설계하며, 불필요한 단계를 제거하고 효율성과 확장성을 높이기 위해 활용 기술을 제안 및 결정한다. 더불어, 고객 VOC 분석 기반 서비스 디자인을 통한 고객 경험과 가치를 창출할 수 있는 고객 서비스를 개발한다.

다섯째, 기술(Technology)이다. DX를 지원하는 디지털 기술과 솔루션 및 플랫폼을 평가/선정하여, 이를 통합/운영하는 과정을 거쳐서 AS-IS 시스템과 최신 기술의 연계와 통합을 통해 비즈니스 가치 창출을 지원한다. 또한, 신규 TO-BE 시스템 설계 및 개발, 운영/관리하기 위한 아키텍처 현대화(Architecture Modernization)와 애자일 아키텍처를 주도한다.

마지막으로 여섯째는 데이터(Data)이다. 기업의 옴니 채널로부터 고객 데이터 수집과 저장, 분석, 활용하는 고객 여정 기반의 프로세스를 의미하며, 빅데이터와 AI 기반 데이터 관리, 분석, 예측과 예지(Intelligence Insight)는 신제품 개발과 고객 데이터 기반의 비즈니스 의사 결정을 지원한다.

* * *

본 정보는 도서의 일부 내용으로만 구성되어 있으며, 보다 많은 정보와 지식은 반드시 책을 참조하셔야 합니다.