본인이 만약에 경영을 하게 되고 전산 인원이 내부에 존재를 하게 된다면 ... 어떻게 전산실을 운영할 것이고 평가를 할 것인가를 생각해 본적이 있었다.
정보시스템의 규모가 크다면 당연히 기획을 하는 일에만 전념을 시키길 것 이다.
하지만, 그렇게 많지도 않은 IT Infra만 물고 빨고 있다면 글쎄다. 생각을 좀 깊게 해야 할 것 이다.
그리고, 내부 정보 시스템에 대한 역량을 Out Sourcing만 관리를 할 것인지에 대해서도 깊게 고민을 할 것 이다.
어느 정도는 개발이나 내부 구조를 알아서 보고서 양식이나 업무 승인을 하는 포인트를 파악하여서 전자결재 없이 약식으로라도 ERP 내부에서 승인처리를 통해서 관리하는 것이 업무의 속도를 높이는 길이 아닐까 생각해 본다.
5 minute experiment with Instagram API by phalkunz |
그렇다면, 우리가 계약 시점에서 Source를 어디까지 확보를 해야할까?
1. 모든 소스를 다 주는 경우
이것까지 다원하는 경우라면 회사의 규모가 엄청나다.
하지만, 성공에 대한 책임과 권한의 문제는 항상 따라 다니는 문제이기 때문에 명확하게 짚고 넘어가야 할 부분이 있는 것이다.
소스 확보보다는 업무를 정립하고 향후에 어떻게 확장이 가능한가에 대해서 고민을 하고 예산을 확보하는게 더 의미있는 일이 아닐까 생각한다.
2. DB 구조를 제공하는 경우
DB의 설계가 잘 되어있어야 의미가 있지 않을까 생각한다.
특히, Core(회계나 특이한 형태의 업무)라고 생각하는 부분은 제외하고 주는 경우에 Open API와 병행해서 제공이 되는 경우들이 많이 있다.
다만, 이 부분 역시도 완료를 앞두고 책임에 대해서 논란의 여지가 있는 부분이기 때문에 구축시에 많은 협의가 필요하다고 볼 수 있다.
3. Open API를 제공하는 경우
누구라도 쉽게 개발할 수 있는 구조로 되어있느냐이다.
개발 기득권을 다소나마 버리겠다는 부분인데 계약만 명확하고 종속이 안되는 기준이라면 마다할 이유가 없다.
분명한 것은 어느 정도의 기술 수준을 가지고 있느냐가 중요하고
4. 관리 모듈만 주는 경우
이런 경우에는 분명히 유지보수를 해한다.
관리모듈이 있어서 개발이 용이하다고 해야 입력모듈 없이 대부분이 조회 모듈만 가지고 적용을 해야할 것이다.
관리모듈은 통상적으로 적용 컨설팅을 할때 사용이 되고 변화관리를 위해서 거의 사용을 안 할 수 있는 부분의 내용인데 ... 이것을 부각시켜서 설명을 할 경우 현혹되지 말아야 할 것 이다.
본인이 CEO라면 전산실장이라면 기본 역량이 되는 제품에 구하기도 힘든 자체 스크립트 구조의 개발 환경보다는 상용 DB(쉽게 이야기하면 적정한 비용에 개발자들이 많은 데이터베이스로 되어있고 쉽게 개발이 가능한 툴 베이스이로 구성이 되어 있는 제품이 좋을 것 이다.
늘 문제는 돈과 관련이 되어있다.
그래서, 비용을 지불하는 쪽에서는 적정한 비용을 정해서 일을 시켜야 하는 것이고
일을 받아서 하는 입장에서는 얼마만큼의 공수 대비 금액을 따질 것이다.
문제는 돈을 아껴서 할려는 이와 돈을 더 받을려고 하는 이 사이에서 의견의 조율이 안 되면 문제가 발생하는 것 이다.
그게 안되면 자기머리는 자기가 직접 깍는 수밖에는 없는 적어도 개발물의 소스나 거기에 준하는 무언가를 확보를 해두는 것이 IT 전략의 목표에 따라서 적용을 하는 것을 조언한다.