저는 공공기관, 지방자치단체, 공공서비스 기업과 민간 기업의 경영진이 IT, 공급업체, 프로젝트에 관한 의사결정을 내리도록 돕습니다. 언제나 발주처의 편에서입니다. 저는 소프트웨어를 판매하지 않으며, 귀 조직의 IT 부서를 대신하지도 않습니다. 항로의 어느 지점에서든 합류하실 수 있고, 지금 필요한 단계만 의뢰하실 수 있습니다.
무엇을 요구할 수 있는지가 늘 분명한 것은 아닙니다. 제 일은 어떤 결과를 기대하는지 묻는 데서 시작합니다.
조직은 무엇이 가능한지 모르기 때문에, 원하는 것을 어떻게 불러야 할지 모르는 경우가 많습니다. 특정 시스템을 요청하는 것은 목표라기보다 첫 아이디어인 경우가 많습니다. 저는 목표와 성공의 정의를 묻고, 체계적으로 분석을 이끈 다음에야 도구를 고릅니다. 시장과 활용 가능한 솔루션에 대한 지식이 저의 가장 큰 역량입니다.
제가 가장 먼저 던지는 질문
- 이상적인 미래를 어떻게 그리고 계십니까?
- 지금 무엇이 가장 불편하십니까?
- 우리는 왜 이 일을 합니까?
- 무엇을 “완료”로 정의합니까(definition of done)?
- 어떤 기준으로 이 프로젝트가 성공했다고 판단하겠습니까?
이런 질문을 스스로 던지는 조직은 드뭅니다. 대개는 곧바로 “그 일에 맞는” 시스템을 가진 것처럼 보이는 회사를 찾습니다. 이는 시간과 비용을 낭비하는 지름길입니다. 시장을 폭넓게 아는 외부 자문은 방향을 잡고, 올바른 질문을 던지며, 공급업체가 아닌 조직 자신에게 가장 좋은 길로 조직을 이끕니다. 그 덕분에 무엇이든 구매하기 전에 실수를 피하고 위험을 줄일 수 있습니다. 과연 우리는 EZD(폴란드 공공기관의 전자문서 시스템), ECM, 케이스 관리(case management), DMS, 워크플로(workflow), BPM의 차이를 정확히 알고 있을까요?
- 사안 및 문서 처리 흐름결재 경로와 의사결정 이력이 중요할 때의 워크플로(workflow)
- No-code, low-code, pro-code프로세스가 조직 고유의 것이고 계속 바뀔 때
- RPA연계가 필요하지만 표준 인터페이스를 쓸 수 없을 때
- AI분석형 AI, 생성형 AI부터 오케스트레이션된 에이전트 시스템까지
- 문서관리 시스템DMS, 때로는 이것만으로 충분하기 때문입니다
- ECM 및 케이스 관리모든 유형의 콘텐츠와 사안을 관리하는 전사적 시스템
- CRM / SRM고객, 공급업체, 이해관계자와의 관계를 프로세스 기반으로, 다채널로 관리
- 절차 변경목표 달성에 새 시스템이 필요하지 않을 때
- 공공 부문 및 전문직 자치단체종이 시대부터 관성으로 이어져 온 절차. 먼저 현 상태를 기술하고, 그다음 무엇을 요구할 수 있는지 살핍니다.
- 공공서비스 기업“KSeF(폴란드 국가 전자세금계산서 시스템) 대응 송장 시스템”, 그러나 그 밑에는 정비가 필요한 구매 정책이 있습니다.
- 기업“CRM이 필요합니다”, 그러나 실제로 필요한 것은 프로세스 기반의 고객 및 견적 관리입니다.
저는 시장에 대한 지식, 20년의 프로젝트 경험, 디자인 씽킹, 구조적인 문제 해결 방식, 그리고 공급업체의 실제 의도에 대한 이해를 제공합니다. 디지털화를 더 단순하고 저렴하게 만들고, 귀 조직의 프로젝트가 처음부터 다르게 진행할 수 있었는데도 수십만에서 수백만 즐로티를 쏟아부은 프로젝트들의 전철을 밟지 않도록 하기 위해서입니다.
저는 모든 것을 알지는 못하지만, 제 지식이 어디서 끝나는지는 압니다. 조직 스스로 무엇을 모르는지도 알아볼 수 있습니다. 그럴 때는 적합한 전문가를 팀에 합류시켜 그 과정을 함께 넘도록 합니다. 자문이 없었다면 조직은 그런 전문가가 필요하다는 사실조차 떠올리지 못했을 경우가 많습니다.
-
IT 시스템 및 프로세스 현황 진단
우리는 실제로 무엇을 갖고 있습니까?
모든 구축 의사결정의 출발점입니다. 시스템, 공급업체, 방향을 선택하기 전에 이미 보유한 것에 대해 명확하고 체계적인 그림을 얻게 됩니다.
- 담당자, 계약, 라이선스, 비용, 지원 종료일을 포함한 애플리케이션 목록.
- 시스템이 지원하는 프로세스와 지원하지 않는 프로세스의 지도, 연계 현황과 데이터를 수작업으로 다시 입력하는 지점의 지도.
- 단일 장애 지점과 공급업체 종속(vendor lock-in)을 포함한 위험 목록.
- 시스템 A/B/C/D 분류와 경영진용 한 장 요약.
2~6주, 공공조달 기준금액 미만.
IT 시스템 현황 진단의 전체 범위 -
요구 분석 및 워크숍
우리에게 정말 필요한 것은 무엇입니까?
조직에 정말 필요한 것이 무엇인지 함께 정리하는 내부 워크숍입니다. 저는 흔히 단순한 질문으로 이를 끌어냅니다. 성공의 정의는 무엇입니까? 이 프로젝트는 언제 성공했다고 평가받게 됩니까? 기업과 공공기관은 이미 다 안다고 생각하거나 깊이 있는 질문을 할 시간이 없어서 이 단계를 건너뛰는 경우가 매우 많습니다. 이는 프로젝트에서 문제가 생기는 가장 흔한 원인 중 하나입니다.
- 경영진 및 매일 해당 프로세스에서 일하는 구성원과의 워크숍: 목표, 기대, 제약 조건.
- 성공의 정의와 프로젝트가 성과를 거두었는지 판단할 기준.
- 지금 무엇이 문제인지, 그리고 앞으로 어떤 모습이어야 하는지에 대한 기술.
- 요구사항 정의나 시장 조사를 위한 시사점, 또는 새 시스템이 필요 없다는 결정.
-
디지털 전략 및 목표 아키텍처
어디로, 어떤 순서로 나아갑니까?
서랍 속에 묻히지 않는 전략입니다. 조직이 실제로 가진 것에서 출발하고, 다음 예산에서 무엇을 해야 하는지 알려 주기 때문입니다.
- 레지스트리, 프로세스, 연계, 접근 권한의 계층으로 구성한 목표 아키텍처.
- 조직이 채택하는 표준: 권한 모델, 인터페이스 표준, 요구사항 문서화 규칙.
- 규제상 의무와 투자를 구분한 로드맵.
- 시스템 구매를 위한 구매 원칙과 투자 및 유지보수로 나눈 예산.
-
요구사항 정의 및 프로젝트 준비
공급업체가 이해하도록 요구를 어떻게 기술합니까?
입찰 공고를 내거나 제안 요청서를 보내기 전에, 귀 조직의 프로세스 언어로 작성한 요구사항입니다. 이를 통해 제안을 비교할 수 있고, 이후 공급업체에 책임을 물을 수 있습니다.
- 인터뷰, 프로세스 맵, 데이터 모델, 연계, 테스트 시나리오.
- 무엇보다 구축의 성공 기준에 대한 답: 왜 이 일을 하며 어떤 결과를 기대하는가.
- 경영진에게 아이디어는 있지만 이를 정리할 시간이 없을 때: 한 번의 대화 후 약 2일 안에 콘셉트나 프로토타입.
-
제안서 평가 및 공급업체 협의
여러 공급업체의 제안을 어떻게 효과적으로 비교합니까?
자체 IT 팀의 권고를 대신하는 것이 아니라 그 곁에 놓이는 독립적인 의견입니다. 경영진은 의사결정의 근거로 삼을 수 있고, 지방의회나 소유주, 그룹 본사 앞에서도 설득력 있게 방어할 수 있는 비교 자료를 받게 됩니다.
- 공급업체에 대한 질문과 귀 조직의 시나리오에 기반한 시연.
- 비교 매트릭스: 공통 범위로 맞춘 제안, 여러 해에 걸친 총비용, 유지보수 및 계약 종료 조건.
- 자회사의 경우 본사 구매 지침에 따른 비교, 필요하면 영어로.
- 발주처 대표로서 공급업체와의 회의 참석.
-
구축, 변화 관리 및 검수
프로젝트를 어떻게 완수하고, 구성원을 설득하며, 공급업체에 책임을 묻습니까?
대규모 IT 프로젝트는 일하는 방식을 바꾸는 변화 프로젝트이기도 합니다. 귀 조직에서는 처음인 경우가 많지만, 제 경험에서는 처음이 아닙니다. 저는 구축 팀에서 경영진을 대표하고, 구성원이 새 시스템을 실제로 받아들이도록 변화를 이끕니다. 경영진은 결정이 필요할 때만 다시 관여하면 됩니다.
- 범위, 일정, 변경 결정의 관리와 변경 및 결정 이력 기록.
- 변화 관리: 커뮤니케이션 계획, 교육, 각 부서의 변화 추진 담당자, 아직 설득되지 않은 구성원과의 대화.
- 경영진을 위한, 그리고 IT 부서, 지방의회, 그룹 본사와의 소통을 위한 짧은 요약.
- 합의된 테스트 시나리오와 기준에 따른 검수, 검증된 데이터 이전.
- 필요 이상으로 한 공급업체에 종속되지 않는 유지보수 계약.
-
경영진 상임 자문
IT 총괄 책임자가 없습니다. 전체는 누가 살핍니까?
해외에서는 “파트타임 CIO(fractional CIO)”라고 부르는 역할이지만, 한 가지가 다릅니다. 저는 IT 부서나 그 예산을 넘겨받지 않습니다. 경영진의 의도를 요구사항으로 옮기고, IT 부서의 권고를 검토하며, 공급업체와의 관계에서 발주처의 이익을 대변합니다.
- 사무국장(행정 책임자) 또는 대표이사, IT 책임자와의 월간 회의, 월간 운영 및 위험 보고서.
- 위험과 핵심 계약에 대한 분기별 검토, 규모가 큰 구매 전 의견 제시.
- 처음 90일: 현황 파악과 시급한 “위험 신호” 식별, 각종 목록 구축 및 계약 검토 착수, 12~24개월 로드맵을 담은 경영진 보고서.
각 단계에 걸리는 기간은 조직과 프로젝트에 따라 다릅니다. 조직의 준비 정도, 조직 문화, 경영진이 부여하는 권한에 달려 있습니다. 그래서 범위와 일정은 첫 상담 후에 정합니다. 가격과 기간이 정해져 있는 것은 IT 시스템 현황 진단뿐입니다.
결정을 지켜 내는 발표. 경영진, 감독이사회, 그리고 더 넓은 의사결정자 앞에서.
자문은 올바른 질문을 던지는 것만으로는 부족합니다. 결정을 내리는 기구 앞에서 전제, 보고서, 프로젝트 결과를 방어할 수 있어야 합니다. 이해관계자를 설득할 전문적인 발표가 필요할 때, 저는 주로 폴란드에서, 또한 미국과 아일랜드에서 한 최소 126회의 컨퍼런스 발표 경험과 경영진, 감독이사회, 더 넓은 회의체 앞에서의 발표 경험을 제공합니다. 저는 기술을 의사결정, 위험, 비용의 언어로 설명합니다.
- 경영진 또는 감독이사회에 대한 프로젝트 권고: 현황, 대안, 비용, 위험.
- 더 넓은 의사결정자 앞에서 보고서와 그 결과를 방어, 비판적인 질문에 대한 대응 포함.
- 컨퍼런스나 업계 포럼에서 프로젝트 콘셉트와 그 성과 발표.
발표 주제: 정보 관리와 정보 흐름, 협업, 전자상거래, 시스템 아키텍처와 연계, 사용자 경험, 그리고 지방자치단체를 위한 업계 컨퍼런스.
같은 항로, 세 개의 서로 다른 출발 항구.
각 그룹은 서로 다른 질문에서 출발하지만, 정보의 혼란에서 설득력 있게 방어할 수 있는 결정에 이르는 길은 같습니다.
단계를 고르시기 전에.
협업은 어떻게 시작합니까?
앞에 놓인 의사결정에 관한 30분 무료 상담으로 시작합니다. 첫 단계는 대개 IT 시스템 현황 진단입니다. 이후의 모든 단계가 그 결과를 바탕으로 하기 때문입니다. 이미 결정이 내려졌거나 프로젝트가 진행 중이라면, 지금 계신 단계부터 시작할 수 있습니다.
한 단계만, 예를 들어 제안서 평가만 의뢰할 수 있습니까?
네. 항로의 각 지점은 별도의 서비스입니다. 좁은 범위로 시작해, 양측 모두 의미가 있다고 판단할 때 범위를 넓힙니다.
각 단계의 비용과 기간은 어떻게 됩니까?
IT 시스템 현황 진단은 2~6주가 걸립니다. 다른 단계의 범위, 일정, 가격은 첫 상담 후에 정합니다. 조직, 프로젝트, 팀의 준비 정도, 경영진이 부여하는 권한에 따라 달라지기 때문입니다.
지금 항로의 어디에 계신지 알려 주십시오. 어디서 시작할지 제안해 드리겠습니다.
- 영업일 기준 2일 이내 회신
- 첫 통화 30분, 무료
- 공급업체로부터 독립