관리 대상 업무 이해 - 성장단계, 처음 구축하는 기업

DX·AIX 출발점 - 4

앞선 편에서 AI는 결국 시스템 위에서 작동한다고 했습니다. 그런데 현장에는 시스템이 갖추어지지 않은 상태에서 AI부터 도입하려는 기업이 있습니다.
그래서 시스템을 구현하기에 앞서, 우리 회사의 업무가 어떤 속성을 가졌는지, 그리고 우리 회사가 지금 어떤 상황에 있는지를 먼저 알아야 합니다. 1·2편이 업무의 속성이었다면, 이 편은 현재 상황입니다.

이런 기업은 대개 소수의 사람이 여러 역할을 나눠 맡고, 스프레드시트나 문서 같은 Office tool을 쓰지만 관리 방식은 개인의 매뉴얼에 가깝습니다. 과제 자료, 실험 기록, 외부에서 모은 정보가 개인 PC와 메일함에 있어서, 담당자가 바뀌면 이어지지 않습니다.

벤처와 성장 단계의 기업이 대표적이지만, 처음 관리체계를 시스템으로 갖추려는 기업이라면 어디든 해당합니다.

개인이 따로 모으는 외부 정보(경쟁사 동향, 기술·규제의 변화)도 마찬가지입니다. 이 정보는 과제의 방향을 정하는 근거가 되지만, 개인에게만 쌓이면 조직의 판단으로 이어지지 않습니다. 시스템으로 옮길 때 이 Intelligence(외부 기술·시장·경쟁 정보) 항목도 함께 볼 대상입니다.

성장 단계는 인원수가 아니라 상태로 봅니다. 설명해야 할 사람이 생겼는가, 사람이 바뀌기 시작했는가 같은 상태가 시스템의 필요를 더 정확히 보여줍니다.

시스템을 정하기 전에 확인할 현재 상황은 이렇습니다.

프로젝트성 업무의 시스템에는 정답이 없습니다

그동안 기업 시스템이라고 하면 재무, 구매, 생산처럼 트랜잭션 업무를 다루는 것이 대부분이었습니다. 이런 업무는 절차와 룰이 정규화되어 있어서, 잘 만들어진 표준을 따르는 것이 정답에 가깝습니다.

그래서 프로젝트성 업무의 시스템도 어딘가에 정답이 있는 것처럼 접근하기 쉽습니다. 잘 만든 표준을 찾아 그대로 들이면 된다는 생각입니다.

그러나 프로젝트성 업무는 다릅니다. 2편에서 본 것처럼, 같은 연구관리라도 프로젝트의 유형, 조직의 규모, 경영진이 중점적으로 보는 것에 따라 필요한 관리 항목과 기법이 달라집니다. 회사마다, 그리고 같은 회사라도 시기마다 최선이 다릅니다.

트랜잭션은 패키지로, 프로젝트성 업무는 현재에 맞춰 시작합니다

1편에서 업무를 프로젝트성과 트랜잭션으로 나눴습니다. 구축 방식도 이 구분을 따릅니다.

기존 패키지가 어떤 역할을 하는지는 이 시리즈 후반부에서 정리하겠습니다.

프로젝트성 업무를 현재에 맞춰 시작해도 되는 이유는, 시스템을 이루는 두 가지가 서로 다르게 다뤄지기 때문입니다.

Application은 업무 절차(Process)를 시스템으로 구현한 것입니다. 소수가 모든 역할을 나눠 맡던 회사가 커지면서 품질, 인허가, 구매처럼 전문 조직이 생기기 시작하면, 업무 절차가 그 조직에 맞게 나뉘고 바뀝니다. 절차가 바뀌면 화면과 기능도 바뀝니다.

그러나 그 절차 위에서 쌓인 과제, 실험, 판단의 기록(Data)은 조직이 바뀌어도 그대로 이어져야 합니다.

Data만 살아 있으면 Application을 바꾸는 일은 상대적으로 쉽습니다. 다만 두 가지 조건이 있습니다. Data를 시스템 밖으로 꺼낼 수 있어야 하고, 기록의 의미가 일정한 형식으로 남아 있어야 합니다.

저희가 구축에 참여한 기업 중에는, 같은 기업이 3년에서 5년 정도마다 시스템을 개편한 경우가 있었습니다. 그때마다 Application은 바뀌었지만, Data는 그대로 새 시스템으로 이어졌습니다.

앞서 0편에서 계획은 내·외부 상황에 따라 계속 갱신되어야 한다고 했습니다. 그렇다고 시스템을 처음부터 그 수준으로 만들자는 뜻은 아닙니다. 시스템은 지금의 관리 방식에서 크게 벗어나지 않게 시작하고, 사용자가 익숙해지면서 나오는 요구에 맞춰 고도화합니다.

그렇게 고도화가 쌓이면 결국 계획을 상황에 맞춰 계속 갱신하고, 그 갱신을 AI가 돕는 관리에 가까워집니다.

gap이 크면 시스템은 겉돕니다

현재의 관리 방식과 새 시스템의 방식 사이의 차이가 gap입니다. 사용자는 이 차이를 입력 항목이 늘거나, 개인이 자기 방식대로 관리하던 것을 정해진 항목과 절차에 맞춰야 하는 부담으로 겪습니다.

이 gap이 너무 크면, 저희가 본 현장에서는 두 가지 모습으로 나타났습니다.

형식적 운영이 더 위험합니다. 돌아가는 것처럼 보여서 경영진이 알아채기 어렵고, 쌓인 Data가 실제와 다르기 때문입니다. 형식적으로 쌓인 Data 위에서는 AI도 겉돌 가능성이 큽니다.

이 상태를 알아보는 신호가 하나 있습니다. 수정 요구가 없다는 것입니다.

저희 경험으로는, 시스템이 잘 운영되는 곳에서는 잔잔한 수정 요구가 계속 나왔고, 잘 운영되지 않는 곳에서는 수정 요구 자체가 없었습니다.

기능이 있어도 활용되지 않는 경우도 있었습니다. 진단을 해 보면 기능이 부족한 것이 아니라, 있는 기능이 쓰이지 않는 경우입니다.

그래서 시작은 현재 사용에서 효용성이 있고, 접근하기 쉬운 상태여야 합니다. gap이 작아야 사용자가 받아들이고, 받아들여야 Data가 쌓입니다.

잘 운영되는 시스템에는 수정 요구가 이어집니다

시스템이 자리를 잡으면 두 종류의 변화가 옵니다.

고도화의 정상적인 모습은 큰 개편이 아니라, 잔잔한 수정이 이어지는 것입니다. 익숙해진 사용자가 요구하는 것이 그 회사에 실제로 필요한 기능이기 때문입니다.

정답이 있다고 보면 완성형을 처음부터 만들고 싶어지고, 미래에 필요할 것 같은 기능을 미리 넣으려는 욕심이 생깁니다. 이 욕심은 안착하지 못할 가능성이 큽니다. 어차피 시스템은 바뀌고, 필요한 기능은 쓰다 보면 요구로 나옵니다. 미리 넣지 말고, 나중에 넣을 수 있게 만들어 두면 됩니다.

정리 — 현재에 맞춰 시작하고, 요구가 나오면 고도화합니다

시스템을 만들기 전에 업무의 속성과 현재 상황을 먼저 알아야 합니다. 트랜잭션은 정해진 룰대로 기존 패키지를 활용해도 되지만, 프로젝트성 업무의 시스템에는 정답이 없습니다. 그래서 현재의 관리 방식에 맞춰 시작합니다.

gap이 크면 시스템은 형식적으로 운영되거나 쓰이지 않습니다. 수정 요구가 없다면 그 신호일 수 있습니다. 시작은 작게, 고도화는 익숙해진 사용자의 요구에 맞춰 이어 갑니다.

그리고 어떤 경우에도 Data는 지켜야 합니다. AI는 그 Data 위에서 작동하기 때문입니다.

다음 편부터는 업종별로 이 기준을 적용합니다. 첫 번째로 화학·소재 산업, 곧 장치산업에서 공정 조건과 변경 이력을 어떻게 다루는지 살펴보겠습니다.

관련 글

[DX·AIX 출발점 · 0편] AI시대 '관리' 재정의 - Paradigm Shift

[DX·AIX 출발점 · 1편] 관리 대상 업무 이해 - 프로젝트성 업무 vs 트랜잭션 업무

[DX·AIX 출발점 · 2편] 관리 대상 업무 이해 - 프로젝트성 업무는 어떻게 나뉩니까