마크베이스 / 홍장희 전무


 

1. 기업 엔터프라이즈 애플리케이션 클라우드 도입 시 쟁점 및 이슈

기업에서 기업 엔터프라이즈 애플리케이션을 SaaS로 도입 결정은 많은 저항에 직면한다. 사용자 측면에서는 사용하는 화면의 변경에 따른 사용법을 습득하여 원활한 사용까지 많은 시간과 노력을 요하므로 변화에 대한 수용이 어렵다. IT측면에서는 기존 IT인력의 보유한 능력을 계속 유지되어 운영 가능 또는 인력의 변화 발생 여부이다.

 

○ 사용자 측면의 저항

  2. 한국에서 기업 엔터프라이즈 애플리케이션을 On-Premise로 구축한다면 거의 대부분이 Global Package를 도입하여 사용자의 요구에 맞게 기능을 추가하여 사용한다. 대표적인 시스템인 ERP를 예로 들면 ERP 기본 Process보다 기존 Process의 기준으로 기능 요구를 한다. 하지만 기능을 추가한 것은 대부분 ERP 사상보다는 편의성 위주의 화면을 고도화를 통하여 추가 또는 보완을 한다. 선진국은 Global ERP Package를 구축하면 기본 입력 기능에 충실하고 조회 등의 필요한 기능만 기능 추가하여 사용한다. 외국계 회사의 경험을 예로 들면 경비 입력 화면이 특정 일자에 변경된다는 Mail을 받는다. 해당 일자 이후에 경비를 입력하러 기능을 실행하면 화면이 변경되어 있고 입력하기위한 방법은 Help화면 제공이 모두이다. 모든 직원이 당일 날 시행착오를 거쳐서 입력 방법을 입력 마감 전까지 알아내서 입력한다. 이런 고생을 하고 나면 자연적으로 방법을 습득하여 이 후는 어려움 없이 처리한다.
  3. 경험적으로 사용자의 조회/입력 화면 요구는 담당 임원의 의사결정을 위한 기능이 포함된 요구로 Process가 변경/추가되고 의사결정을 위한 분석용 정보도 수반되어 조정되어 진다. IT의 기술이 진화되면 사용자의 사용 방법도 변화 될 수밖에 없다.
  4. 기업은 그림 1과 같이 사업의 종류가 다양하다. 즉 제조, 서비스, 물류의 사업이 혼재되어 있다. 또한 제조는 생산 제품에 따라 주문, 프로세스, Lot-Base 또는 Lean(도요다 생산방식)의 형태로 이루어져 있다. 생산은 단순하게 생산계획 및 실적으로 관리가 가능하지만 원가를 산출하는 것과 연계를 하면 상황은 달라진다. 국내는 표준원가 보다는 실제원가로 산출을 요구하므로 시스템 구축 시 해당 생산방식에 맞는 원가 산출을 위한 기능 개발이 이루어진다. 이는 회사의 생산품목(생산방식) 또는 사업 방법에 따라 실제원가 산출을 위한 배부 방법이 다르다.
  5. 그러므로 생산/원가에 맞는 기능을 갖추기 위하여 기능을 가지고 있거나 기 만들어진 기능을 도입하여 회사에 맞게 조정하는 작업을 거쳐 완성하려 한다.

 



 

○ IT 측면의 저항

  2. ERP를 SaaS로 변경한 후 기존 ERP관리를 위한 인력을 계속적으로 유지할 수 없다. SaaS로 변경 시 신규 인력이 필요할 수 있다.
  3. 기존 이력 정보를 조회하는 업무에 대하여 시스템을 구 ERP 시스템을 유지해야만 가능하다. 법적으로 5년의 이력 정보를 유지하려면 5년간의 시스템 유지가 필요하다.
  4. IT인력을 2중으로 보유할 수 없으므로 IT의 유지보수 방안에 부담이 있다.
  5. 과연 SaaS로 변경하였을 시 비용이 절감할 수 있다는 것에 대하여 면밀한 검토가 필요하다. 일반적으로 클라우드 서비스 제공 업체는 5년 TCO를 제사하는데 시스템의 사용 수명은 10년 이상 되는 경우가 대부분이다. 예로 모 대형마트에는 현장 시스템을 아직도 AS400으로 개발된 화면을 사용하여 운영한다.

 



 

2. 사고의 전환

엔터프라이즈 애플리케이션을 SaaS로 도입하려면 임대의 사고로 전환이 필요하다. 요즘은 감가상각을 하는 물품에 대하여 자산을 직접 소유하는 것에서 리스 또는 렌탈을 제공하는 서비스업체가 늘어나면서 서비스를 도입하는 추세이다.

 

○ 자동차 사례

기업에서 업무용 자동차를 많이 사용하고 있다. 불과 몇 년 전만 하여도 용도별 여러 종류의 자동차를 구입하고 각 자량 별 종합보험을 가입하고 유지보수를 위해 지정 정비소를 두고 유지 보수하였고 차량 구입의 금액은 고정자산관리로 감가상각을 하였다. 그러나 현재에도 기업이 자체 구입/운영을 하는가? 아마도 모두 리스 또는 장기 렌탈로 운영을 하고 있을 것이다. 이는 자금 운용 측면을 보면 차량 구입을 위한 금액이 일시 사용을 피하고, 유지보수를 위한 인력 또는 비용 절감을 한다. 그렇지만 이런 변화로 인한 인력의 변화가 있었냐 하면 그대로 유지하면서 좀더 가치가 있는 업무를 수행하고 있다.

리스 또는 렌탈의 서비스를 제공하는 업체는 여러 개 있다. 기업의 여러 주변환경 및 제공 서비스를 검토하여 적합한 서비스업체와 계약하여 운영하고 있다. 리스 또는 렌탈 서비스 업체에게 서비스되는 차량을 개조/개선 요청은 없다. 단지 계약 시 일부 편의성 추가 요청이 있어 조정이 있을 뿐이다.

○ 컴퓨터 사례


요즘은 사무실 또는 공장에서 사용되는 데스크탑 또는 노트북 컴퓨터는 렌탈하여 사용한다. 왜냐하면 H/W의 사양이 단기간에 Upgrade되어 Life Cycle이 짧아지고 있고, OS 및 사용 S/W의 Version이 예전보다는 빠르게 발전하여 출시되고 있다. 이런 변화로 컴퓨터의 구입 주기가 빨라지므로 대응하기 위한 비용이 증가한다. 그리고 짧은 기간에 컴퓨터가 필요한 업무가 가끔 발생한다. 기존에는 이런 상항을 대비하여 컴퓨터를 보유하므로 구입하여 저장하는 공간, 컴퓨터의 상태관리, S/W유지 등의 관리가 필요하지만 요즘은 렌탈을 하여 사용한다. 왜냐하면 필요할 시 원하는 사양의 컴퓨터를 제공받아 활용한다. 그러므로 적은 비용으로 최상의 컴퓨터를 사용하고 보관 및 S/W관리가 필요 없어진다.

또한 업무용으로 한글오피스 또는 MS오피스가 SaaS로 제공되고 사용하는 것이 추세이다.

 



 

3. 전통적인 기업의 시스템 아키텍처

기업에서 엔터프라이즈 애플리케이션의 도입 과정을 보면 최초에 메인 프레임 환경에서 단위 업무용(Process Level1) 기준인 생산, 영업, 구매, 재무/회계, 인사/급여 등을 자체 개발하여 운영하였다. 그러다가 통합된 시스템이 요구되면서 ERP가 경쟁적으로 도입하여 구축하였고, 그 후 ERP 고도화를 통하여 EPM/BI가 적용되고 PLM, SRM, CRM, S&OP 등이 ERP를 기준으로 도입되었고 이들 시스템간 연계가 대두되면서 EAI가 추진되었다. 이렇게 메인 프레임 시절에도 단위 업무간 연계가 어려움이 대두되었고 상호간 많은 노력을 하여 연계 작업을 하였으나 쉽지는 않았다. 왜냐하면 각 3. 전토단위 업무의 책임 임원 간의 알력이 존재하여 쉽게 연계가 안되었고 대부분 합집합 개념으로 연계로 추진되어서 표준 기반 연계가 아닌 처해진 상황에 맞게 연계하는 방향으로 추진되었다. 그럼 ERP를 기반으로 EAI를 통한 다른 애플리케이션간 연계는 어떠 하였냐 하면 동일한 문제로 어려움을 겪었다. 이를 해결하기 위하여 나온 것이 MDM이었고 이 또한 애플리케이션 들의 정보 합집합으로 연계가 이루어졌다.

 



 



 

4. SaaS Cloud 도입을 위한 Orchestraction

엔터프라이즈 애플리케이션은 거의 모든 영역에서 구축한 기업도 있고 준비 중인 기업도 있다. 그리서 최신 기술을 반영한 시스템으로의 변경 도는 도입을 고민하는데 매인 프레임, ERP/MDM/BI 및 IoT 와 Cloud를 경험한 바탕으로 방향성 결정에 도움이되는 내용을 조심스럽게 제시해 보겠다.

 

○ 아키텍처


아키텍처를 생각하기에 앞서 엔터프라이즈 애플리케이션을 어떤 클라우드 서비스로 할 것인가 여부를 생각해야 할 것이다.



 

회사의 고유 기능으로 범용성이 없다면 IaaS 또는 PaaS로 고려하는 것이 좀더 효율 적일 것이다. 예를 들어 MES 또는 MOS는 해사의 공정 또는 설비에 특화되게 시스템이 구축되어야 한다. 따라서 SaaS로 구축한다 하면 상당히 어려움이 따를 것이다. SaaS로 서비스를 하려면은 MES, POP, Edge 등을 연계하고 설비의 레시피 컨트롤을 위한 기준정보의 표준화를 해야만 가능 할 것이다. 요즘 독일과 공조한 AAS(Asset Administration Shell)가 완성되어야 고려해 볼 수 있다.

지금은 개선되었는지 모르지만 베트남 등지에서 상대적으로 인건비가 낮은 지역에서는 인터넷환경의 통신이 종종 단절되어 열악한 경우가 있다. 여기는 클라우드 보다는 On-Premise로 검토하여 배치로 계획과 실적을 연계하는 방향으로 고려하는 것이 좋을 것이다.

 



 

그림3과 같이 어떤 엔터프라이즈 애플리케이션을 IaaS, PaaS, SaaS를 할 것인가 또는 On-Premise로 할 것인가를 결정해야 한다.

 

○ 표준화

표준화에는 보편적으로 2가지를 고려 할 수 있다. 첫번째는 프로세스 표준화고 두번째는 기준 정보의 표준화이다. 클라우드를 통한 시스템 아키텍처를 Orchestration하려면 우선 MDM이 되어야 한다.

 

○ 검토 사항



 

만약 SaaS를 도입하려 한다면 우선 해당 엔터프라이즈 애플리케이션에서 요구되는 업무영역에서 요구되는 기능을 정리해야 한다. Process의 Level3가 아닌 Level4~5까지 정리되어야 한다.

그런 다음 클라우드 서비스 제공업체가 제시하는 기능을 Mapping한다. 이때 정보의 입력 기능의 편의성보다는 항목이 포함되어 있는지에 주력해서 파악한다. 그리고 조회는 분석의 편의성을 확인한다. 요즘 SaaS를 검토할 때 기능 추가에 노력하는 경우가 있는데, 앞의 예시인 자동차, 컴퓨터 렌탈과 같이 제공하는 기능을 그대로 사용한다고 생각해야 한다.

 

○ 기능 검토

ERP를 예를 들면 사용자 측면의 저항에서 언급한 것과 같이 생산 제품 또는 설비가 다르면 생산 방식이 상이하고 이에 따른 원가 산출법도 다르다. 시중에 출시되는 SaaS로 제공되는 제품이 모든 생산 방식을 만족할 수 잇는 기능을 현재 보유하기는 어려울 것이다. 이런 문제를 해결하기위해 기능 추가를 하는 것은 자동차 렌탈 서비스계약에서 컨셉트 카를 만들어 달라는 것과 같다. 따라서 표준화된 기반에서 MOM(Manufacturing Operations Management)을 SaaS로 도입하고 이것을 기반을 원가 산출하는 방법을 검토하는 것도 하나의 방법일 것이다. 즉 사고의 전환의 사례를 보면 서비스제공자에게 기업 나만의 필요한 기능을 요구하여 사용하지는 않는다. 이는 기능을 만드는데 비용이 들어가고 SaaS 서비스 사용의 비용이 투입되므로 2중 투자가 된다. SaaS는 시스템이 변하는 것이 아니라 사용자가 기능에 맞게 적응하는 것이다.

 

○ 인력의 Skill

엔터프라이즈 애플리케이션을 SaaS로 도입하면 시스템관리자가 없어도 되는 것과 같은 인식이 있는데 잘못된 인식이다.

SaaS를 프로젝트를 하면서 발생한 사례를 이야기하자면,

  2. 시스템이 갑자기 Down되었을 시 계약 사항은 1시간이내 복구이다. 이 때의 처리 프로세스는 전화 또는 Mail로 긴급서비스요청을 한다 그러면 바로 접수되어 추진하지만 그동안 진행사항은 아무것도 공유되는 사항이 없다. 그러다 갑자기 네트워크 등 주변 환경의 변화가 있는지 확인 Mail이 온다. 이 상황에 시스템관리자가 있다면 사전에 여러차례 문의될 환경을 미리 제시하면 상당히 빠르게 완료된다.
  3. Data의 Backup이다. 방법을 제시하지만 Backup Data의 관리 및 Restore의 실행
  4. 시스템의 부하도 및 저장공간의 상태 등을 제시하고 있고 관리를 대행한다는 서비스 포함이 있다.

위의 내용의 업무는 시스템관리자가 있어야 커뮤니케이션과 관리가 가능하다.

 

○ TCO의 검토

클라우드는 서비스의 과금은 H/W에 일시적 투자에 대한 비용을 S/W의 사용 금액으로 전환되어 있다. 따라서 10년이상 특별한 변화가 없어 엔터프라이즈 애플리케이션을 사용한다면 SaaS의 도입은 TCO의 검토를 수반하여 PaaS로 검토도 필요 한 것으로 보인다.

 



저작권 정책

K-ICT 클라우드혁신센터의 저작물인 『기업 엔터프라이즈 애플리케이션 클라우드 도입 방향』은 K-ICT 클라우드혁신센터에서 마크베이스 홍장희 전무에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.