UiPath RPA Developer Certificate

이미지
관련 링크 ( https://www.uipath.com/rpa/academy/certifications ) UiPath Certificate를 받았다. 2018년 12월 말까지 무료로 시험을 볼 수 있다. Training Course가 도움이 많이 되었다. 시험은 2단계로 진행된다. 각 단계는 3번까지 Retake 가능하다. 1단계 필기, 2단계 실기 시험이다. 교육 코스들을 완료 했다면 많이 어렵지는 않다. 특히 2단계는 "Level 3 - Advanced Training"가 많은 도움이 된다. 반드시 코스를 완료하고 시험을 보기 바란다. 1단계 필기는 검색능력과 약간의 운이 있다면 패스가 가능할 수 있으나 2단계 실기는 조금 얘기가 다르다 . 실제 코딩이 가능해야만 패스가 가능하다.

Completed elearning course of Automation Anywhere

이미지
TOP 3 RPA 솔루션 중 하나인 AutomationAnywhere의 온라인 코스를 완료했다. AutomationAnywhere는 Test automation을 목표로 시작했으나 최근들어 RPA 솔루션 방향 전환을 했다. 이상하지만 이와 동시에Trial 버전 제공을 중지했다. AutomationAnywhere도 UIPath 처럼 온라인 training course를 제공하고 있으나, 조금 치사(?)하게 운영하고 있다. 먼저 AutomationAnywhereUniversity에 가입한 후에 코스 등록을 요청하면 기준은 모르겠으나 심사후 허가해 주는 순서로 진행된다. 심지어 Trial 버전도 제공하지 않고 그냥 비디오 시청을 통해 간접 경험만을 허락하고 있다. 솔루션에 자신이 없어서 인지, 한번써보면 구매하지 않을것이라 생각하는 것인지 알수가 없다. 시대에 뒤떨어지는 의외의 신비주의라 조금 답답하다. 간접경험에 의하면 Test Automation으로 시작해서 그런지 개발자 Friendly한 환경을 제공하는것으로 보인다.  개인적으로는 UIPath가 RPA에 있어서는 조금더 유용해 보인다. AutomationAnywhere는 상당히 많은 기능을 제공한다. 하지만 Test가 아닌 RPA 관점에서는 과하다는 생각이 든다. 해외에서는 SAP의 자동화가 중요한 부분인것 같다. 다른 솔루션과 마찬가지로 SAP만을 위한 자동화 기능이 상당하다. 국내에서는 과연 가치가 얼마나 있을지 모르겠다. 전사적으로 SAP를 도입한 기업이 제한적인 상황인데 말이다. RPA 솔루션 도입시 마켓에서의 위상도 중요하겠으나, 기능의 다양성은 복잡도와 정비례하며 편의성과는 반비례하기에 기업내 애플리케이션 환경을 고려하여 솔루션을 선택하는 것이 중요하다고 생각한다. 너무 과하면 안하는것만 못하다.

Completed UiPath Orchestrator 2016.2 Training

이미지
UIPath의 서버 제품인 Orchestrator 에 대한 Training이다. Agent관리와 Agent와 Process간의 관계 설정, Transaction 모니터링 등의 기능을 하는 서버 제품이다.

Free RPA - Workfusion RPA Express

이미지
Workfusion은 RPA 분야의 Strong Performer 중 하나이며, Free RPA Tool을 제공하고 있는 기업 중 하나이기도 하다. UIPath와 마찬가지로 RPA Core Tool을 무료로 제공하고 있다. Workfusion은 이러한 Free RPA 배포 전략으로 시장을 키우고 있다고 주장하고 있으나, 이를 두고 일부에서는 막 형성되고 있는 RPA 시장을 망치고 있다고 비난하기도 한다. WorkFusion의 RPA Express의 장단점을 파악을 위해 설치 후 사용해 볼 것이다. RPA Express는 등록후 Email로 받은 Download link를 통해 받을 수 있다. 예상보다 용량이 상당하다.(over 2GB) 시스템 최소 요구 사항도 높은 편이다. (4core 이상 메모리 8GB 이상)

RPA 솔루션

이미지
<UIPath Studio> UIPath는 효율적으로 만들어진 솔루션이라 생각된다. Windows Workflow Foundation (WF)을 기본 Framework으로 선택하고 필요 Activity의 구현을 통해 확장해 나가는 전략으로 구현되었다. 이로 인해 Custom Activity를 추가 할 수 있는 구조가 되었고 동시에 오픈 플랫폼의 역할도 하게 되었다. 우리는 필요에 따라 Activity를 구현하고 UIPath Studio에서 사용할 수 있다. 참조:  <How to create a custom activity-UIPath>   UIPath Studio는 Re-hosted Workflow Foundation Application이다. MS는 WF Designer를 직접사용하거나 자신의 Application에 Rehosting해서 사용할 수 있게 제공하고 있다. 이는 솔루션을 개발하는 입장에서 상당히 매력적이다. 특히 솔루션에서 Workflow를 제공하거나 기반으로 해야할 경우는 더욱 그렇다. 물론 Rehosting 할 경우 직접 사용할 경우에 비해 제약이 존재하지만 말이다.  UIPath PLATFORM은 Studio, Orchestrator 그리고 Robot으로 구성되어 있다. Studio로 만들고 만들어진 것들을 Orchestrator을 통해 통제하고 Robot이 실제 Automation을 실행한다.  <UIPath Orchestrator> 솔루션이 Enterprise 레벨로 서비스를 하기 위해서는 코어엔진 이외에 다양한 것들을 만족해야 한다. 예를 들어 보안, 모니터링, 로깅 등의 관점의 서비스가 포함되어야 하고 이런 도구들을 통해 신뢰성, 정확성, 안정성, 보안성 등의 품질 속성을 만족해한다. 사실 이과정이 개발에서 있어서 시간이 많이 필요한 부분이라 생각한다.  UIPath Studio를 확장하기 위한 C...

RPA vs. BPM: 하나의 목표, 2 개의 솔루션

이미지
RPA vs. BPM: One Goal, Two Solutions   <원본> "로봇 프로세스 자동화(RPA)는 정말 새로운 것인가? 라는 질문을 많이받는다. 완전히 혁신적인 기술을 찾고 있었다면 너무 기대하지는 마라.  RPA의 뿌리는 소프트웨어 로봇의 발전 속에서 찾을 수 있다. 따라서 RPA는 이것의 조상 또는 사촌인 비즈니스 프로세스 관리와 닮아 있을지도 모른다. BPM (가끔 "비즈니스 프로세스 자동화"와 혼용됨)은 특정 소프트웨어가 아닌 비즈니스 프로세스를 간소화하고 효율성과 가치를 극대화하는 방법이다. 프로세스가 어떻게 작동되고 있는지, 개선 분야는 어디인지 파악하고, 솔루션을 처음부터 끝까지 구축하기 위한 방법을 상세하게 검토한다. BPM은 비즈니스 프로세스의 인프라가 견고하다는 것을 확인하는 것이다. 반면 RPA는 인간처럼 프로세스를 조작하기 위해 설계되었기 때문에 좀더 표면적인 레벨(UI 같은)에 존재한다고 할 수 있다. 구현이 좀 더 빠르고 모든 소프트웨어에서 바로 사용할 수 있으며, 변화하는 세계에 적응하도록 쉽게 변경하거나 업데이트가 가능하다. 우리가 보기에는 RPA와 BPM은 서로 상충되지 않는다. 서로 다른 구현 전략을 가지고 같은 목표를 달성하고자 하는 것이다. 이전에 사람에 의해 처리되던 빈도 높은 프로세스를 처리하기 위해 RPA를 사용하는 동안 실제로 필요한 것은 워크 플로우에 대한 정밀 검사 정도이다. 예를 들어, 특정 유형의 트랜잭션이 조직의 서비스의 핵심 요소 인 경우, 프로세스가 가능한 긴밀하고 효율적이고 독립적임을 확인해야한다. 표면 수준의 수정에 의지하는 것이 아니라 프로세스 자체를 변환해야하는 경우가 있는데 이럴 때  BPM을 사용하는 것이 적당하다. 물론, 우리 모두는 비즈니스 구조를 변화시키는 것이 항상 실현 가능한 것은 아니라는 것을 알고 있다. 이런경우 많은 개발과 많은 투자 (시간과 돈)가 필요하다는...

Graduated the RPA Developer - Foundation Training for UIPath

이미지
<RPA Developer - Foundation Training Certificate> "25 Hours 33 Minutes" 전체 코스를 완료하는데 소요된 시간이다. 어려운 것은 없으나 상당한 끈기를 요하는 코스다. RPA에 대한 기본적인 이해를 얻기에 도움이 된다고 생각된다. Workflow 내에서의 프로세스 구현을 위한 변수, 루프, 조건 처리 등에 대한 내용과 외부 프로그램 연결을 위한 selector에 대한 개념, UI element로 인식 불가한 여러가지 경우를 대비해 고안한 방법들에 대한 것들이 주를 이룬다. <Full index of the course> UI Element또는 HTML Element를 식별하기 위한 유니크한 정보가 없을 경우에 이를 식별하기 위한 방법을 여러가지 고안했다. Object 또는 DOM tree내의 index를 이용하거나 레이블을 이미지로 인식하고 그와 관련된 Edit 박스를 anchor를 이용해서 관계를 설정한다거나 하는 방법들이다. 어떠한 방법이 최적인지는 상황에 따라 Developer가 선택해야 한다. 이는 application과 html dom tree 등에 대한 이해가 Developer에게 요구된다는 의미이다  . 분명히 식별 가능한 object에 대한 스크립트는 빠르고 쉬울수 있으나, client의 환경은 생각보다 복잡하고 다양하다. RPA 솔루션 도입을 위한 검증 과정에서 적용 가능한 프로세스의 정립도 중요하지만, 업무용 SW의 인식(?) 또는 자동화 가능 정도를 반드시 검증해야 한다.