테이블의 레코드분, 루프하는 처리로 이끼하면···?

로봇 디자인으로 넘어지기 쉬운 곳

엑셀에 기재된 40명분의 유저에게 각각 전용의 BOX 폴더를 작성하는 로봇을 작성한, 나.

BOX 폴더는 액세스하는데 폴더 ID가 필요하기 때문에, 작성하면 담당자 마스터의 Excel에 ID를 기입해 갈 예정.

흐름은 간단하고
담당자 마스터 Excel 로드 ⇒ 메일 주소를 KEY에 BOX 폴더를 작성⇒⇒ 폴더 ID 를 마스터에 기입
의 흐름입니다.

드디어, 릴리스가 되어, 첫회, 모두가 지켜보는 중, 처리 실행 개시! !

【Start】
첫 번째, 작성 OK
두 번째, 작성 OK
　:

20명째로 뭔가 이끼 버렸다 → 로보 정지. 오류 메일 전송.
【End】

BOX상에는 19인분의 BOX 폴더와 아무것도 갱신되지 않은 담당자 마스터가 남는다.

오류 원인을 조사! !
어디까지 갔는지, 담당자 마스터의 Excel을 봐도 모르기 때문에, 로그를 쫓는다→20명째로 코케타의 것을 알 수 있다→원인을 조사→알았다! 해결

그런데, 재실행(아, BOX의 폴더 지우지 않으면···19인분의 폴더 지우기→재실행!이번이야말로!)

【Start】
첫 번째, 작성 OK
두 번째, 작성 OK
　:
21명째로 뭔가 이끼 버렸다 → 로보 정지. 오류 메일 전송.
【End】

BOX상에는 20명분의 BOX 폴더와 아무것도 갱신되어 있지 않은 담당자 마스터가 남는다.

마음의 목소리

유저 「일단, 할 수 있는 사람만으로도 사용하고 싶지만」

나 　 "아, BOXID가 걸리지 않기 때문에 사용할 수 없어...
　　　　　도 ,,, 좀 더 기다려 주세요 」

유저 "지------. (빨리 해)"

※이것이 야간 배치였던 경우, 다음날 아침부터 사용할 수 있다고 생각했던 사람들로부터의 압력을 받는 케이스도 있습니다

루프 구성

눈치채는 분도 계신다고 생각합니다만, 어느 리스트에 대한 일련의 처리를 할 때에는 2 패턴의 설계가 있습니다.

아

B

요약

이런 루프는 절대 도중에 이끼이므로, 「할 수 있는 곳까지 했습니다 로보」로 하는 것을 추천합니다.
(혹은, 유저와의 사양 결정의 때에, 제로이치로보인가 역시 로보인지를 인식해 둔다)

에러는 Try-Catches로 받아들인다.
라고 하면, 나중에, 안 되었던 사람만 플래그하고 재실행하면 된다. 같은 바람에도 할 수 있습니다.
오류를 잡으면 로봇을 중지해야한다는 것은 없습니다.

RPA화할 때 "수작업을 그대로 RPA에 재현시킨다"는 방법을 취하면 이 루프에 빠질 가능성이 높습니다.

인간의 방식으로는 「정렬해 주는 것이 효율이 좋다」 때문에, 각 처리마다 정리해 버리는 흐름으로 하고 있는 것이 많다고 생각합니다만, RPA에서는 정리해 해도, 1건씩 모두 의 작업을 흘려도 거의 변하지 않는 케이스가 많기 때문에, 그러한 시선에서의 설계가 중요하다고 생각합니다.

이상, 자주 있는 사례 소개였습니다!