이는 구조화된 아키텍처 규율과 가속화된 민족학 연구 기법의 균형을 맞춘 신속한 지식 캡처 방법론이 필요합니다. 이 접근법은 암묵적 지식을 외부화하기 위해 기능 매핑 프레임워크를 사용하는 집중적인 협업 워크숍을 중심으로 합니다. 분석가들은 동시에 시스템 접점을 역설계하여 가설화된 가치 흐름을 실제 거래 데이터와 검증해야 합니다. 이 이중 경로 방식은 문서화된 기능이 전문가 증언과 객관적인 시스템 현실 모두를 반영하도록 보장합니다.
나는 글로벌 3PL 제공업체가 인수하는 중형 물류 회사를 분석하기 위해 참여했습니다. 목표 회사는 20년 동안 구술 전통에 기반한 프로세스 정의로 운영되었습니다. 그들의 모든 고객 온보딩 논리는 10일 내에 은퇴할 두 명의 운영 관리자 머릿속에만 존재했습니다. 매입자의 ArchiMate 기업 아키텍처는 3레벨 세분화까지 표준화된 기능 분해를 요구했습니다. 그러나 가상 데이터 룸은 NDA 조건에 따라 72시간 내에 종료되었습니다.
전문가와의 일대일 인터뷰를 순차적으로 진행하고 세션을 녹음하여 나중에 전사하는 방안을 고려했습니다. 이는 깊은 맥락 이해를 제공하고 세부 질문을 허용할 것입니다. 그러나 이 접근은 40개의 주요 기능을 모두 다루기 위해 최소 5-7일이 필요하므로 검증이나 교차 참조 여유가 없었습니다. 실시간 조정 없이는 두 전문가 간의 상충하는 해석 가능성이 높았습니다.
우리는 Miro 보드를 사용하여 미리 채워진 TOGAF 기능 템플릿으로 12시간의 집중 워크숍을 병행하여 진행하기로 결정했습니다. 이는 전문가 간의 실시간 합의를 강요하면서 동시에 그들의 진술을 레거시 AS/400 데이터베이스의 SQL 쿼리 결과와 교차 참조했습니다. 이는 주장된 프로세스 단계가 실제 데이터 흐름에 대해 즉시 검증되었습니다. 이 방법은 참가자에게 힘든 작업이었지만, 암묵적 지식이 48시간 내에 외부화되고 검증되도록 보장했습니다.
우리는 원하는 40개 기능 중 38개를 완전한 ArchiMate 관계로 문서화하는 데 성공했습니다. 나머지 두 개의 기능은 높은 위험 지식 격차로 표시되었습니다. 이를 통해 매입자는 미래 프로세스 재설계 비용을 감안하여 구매 가격을 15% 인하하는 협상을 할 수 있었습니다. 아키텍처 팀은 데이터 룸이 닫히기 전에 ServiceNow 저장소 내에서 통합 계획을 시작할 수 있는 충분한 세부 정보를 갖추었습니다.
질문 1: 전문가가 직업 안전을 보호하기 위해 고의적으로 프로세스를 혼란스럽게 하는 경우, 비즈니스 기능을 어떻게 검증합니까?
이는 전문가 증언을 시스템 로그, 물리적 문서 아티팩트 및 출력 산출물과 비교하는 삼각 측량 기법이 필요합니다. 전문가들이 문서화를 거부할 경우, "프로세스 리허설" 세션을 설계하여 그들이 결정 사항을 설명하며 워크플로우를 시연해야 하도록 합니다. 이는 그들이 단계를 추상화하거나 생략하는 능력을 효과적으로 우회합니다. Salesforce 사례 기록이나 Oracle 워크플로우 엔진의 타임스탬프를 교차 참조하여 주장된 사이클 타임 및 의사 결정 분기를 검증합니다. 이는 그들의 서사에서의 격차를 노출시키는 감사 추적을 생성합니다.
질문 2: 기업 아키텍처에서 비즈니스 기능과 비즈니스 프로세스의 주요 차이는 무엇이며, 이를 혼동하면 통합 실패를 초래하는 이유는 무엇입니까?
비즈니스 기능은 특정 결과를 달성하기 위한 조직의 능력을 나타내며, 프로세스 변화나 기술 변화와 관계없이 안정적입니다. 예를 들어, "고객 신용 평가"는 수동 Excel 검토나 자동 AI 위험 평가를 통해 실행되더라도 지속됩니다. 반면, 비즈니스 프로세스는 그 기능을 실현하는 활동의 특정 흐름을 설명합니다. 이를 혼동하면 목표 회사가 워크플로를 수정할 때 깨지는 경직된 통합이 발생합니다. 기능 기반 계획을 통해 매입자는 전략적 기능을 유지하면서 프로세스를 대체할 수 있습니다.
질문 3: 문서가 없고 원래 개발자가 사용 불가능할 때 레거시 코드에 내장된 암묵적 비즈니스 규칙을 어떻게 처리합니까?
코드 고고학에 출력 분석을 결합하여 사용합니다. COBOL 복사본, PL/SQL 패키지 또는 Java 클래스와 같은 리포지토리에서 실행 가능한 논리를 추출합니다. 샘플 입력을 시스템에 투입하여 출력을 관찰하고 결정 테이블 재구성을 사용하여 조건부 논리를 역설계합니다. 이러한 발견을 현재 상태의 프로세스 관찰과 연관시킵니다. 코드 동작이 명시된 비즈니스 규칙과 모순되는 경우, 이 코드를 준수 목적으로 사실로 취급하고 이를 의도된 요구 사항이 아닌 "발견된 제약"으로 문서화합니다.