Balaji Loganathan

In the RPA platform where most of the time a robot executes at virtual machines, specifically in the case of the unattended robot where a user doesn’t have visibility of the processing part. RPA is rule or logic-based, It works like a human being (can automate specific tasks, replicate manual work keystroke by keystroke, calculating, data entry, automatic form fill, repetitive process, etc) RPA can be integrated into existing businesses for higher productivity
This reduces costs and eradicates errors that are common in back-office practices like data entry or invoice processing.  
In such situations, it becomes very significant to deal with the exceptions in the robot.
 
RPA Exception Handling
 
With the exception mechanism, we can write codes considerably “cleaner” and then have everything “automatically handled” and user-friendly.
 
Below are the four exception-handling mechanisms
·         Continue
·         Ignore
·         Retry
·         Abort
 
Continue - The Exception is rethrown
Ignore - Execution can continue from the next step after ignoring the exception
Retry - Activity with the exception is retried (# of attempts can be counted)
Abort - The Execution is aborted
 
When an exception is thrown, it should offer paths to take for further processing. This makes it much easier to handle exceptions meaningfully even when you don't know the exact context of their creation. This forces the programmers to
code exception handling very close to the decision-making hard-coded into the operation.
 
The most common errors in RPA can be classified into business exceptions or application exceptions.
When a software BOT is unable to process a transaction with programmed commands, In other words, the business exception is written into the automation’s exception code.
 
Example - 1 A robot processing invoices in a manufacturing firm may be programmed to process invoices up to $5,000. When it comes across an invoice valued at $8,000, the bot identifies it & is unable to process it, and throws a business exception alert.
 
 Example -2 if an RPA bot involved in onboarding new associates comes across an incomplete form that is missing the new associate’s PAN number, the bot will identify it must have this field to continue with the flow and throw a business exception.
 
In both cases, the robot records the exception and moves on to the next transaction.
An application exception happens when a robot encounters a technical issue, such as a server/System crash, or a change to the technology environment that requires interaction with a new application or website.
 
For example - A robot that must click a log-in button on a web application stops when the webpage does not completely load; sometimes these errors are incidental and can be fixed by repeating a few scopes of the process.

Shainin RED X projects are evidence-based; converging on the main source of variation, the emphasizing principle is DY = f(Dx)The largest value will result from a combination of a significant coefficient and a large change in X.  
 
What is the difference between Shainin and Six Sigma?
 
The main difference between the Shainin Red X® approach (FACTUAL) and the Six Sigma methodology (DMAIC) is the phase Approach. The Red X develops a strategy based upon the physics of the problem and the comparison of the BOB (Best of Best) and WOW (Worst of Worst) parts
 

 
Any problem-solving methodology involves two phases’ diagnostic and remedial phases. The diagnostic phase is concerned with measuring and analyzing the current process performance while the remedial phase involves of various corrective actions taken to improve the process and monitoring the new process to make it a culture.
 

 
Tables show the comparison between the six sigma and Shainin methodological approaches.
 
The basis for Comparison
Six Sigma
Red X
Meaning
Six sigma methodology attempts to improve the existing process
The Shainin System™ (SS) is defined as a problem-solving system designed for medium- to high-volume processes where this methodology follows FACTUAL approach.
Focuses on - 
Process Focused
Red X statistical engineering identifies a set of tools first used to identify the Red X, and then to monitor the effectiveness of controlling the Red X. Shainin system  focuses   on  understanding  the  machine  or  parts  problem  and assembly operations facilities
Methodology
Six Sigma uses DMAIC (Define, Measure, Analysis, Improve, control)
Red X approach uses the following structure, called FACTUAL (Focus, Approach, Converge, Test, understand, Apply, Leverage
Domain Knowledge
No Deep understanding is required of the Y & the problem
You must have a deep understanding of the Y and the problem.
Tools used
Descriptive statistics. Regression analysis, designed experiments, hypothesis tests, analysis of variance (ANOVA), and control charts.  
Shainin systems are  such  as  Isoplot,  Multi-Vari  analysis,  Concentration  Chart, Component  search,  Paired  comparison, Product/Process search,  Variable  search,  Full factorial,  B versus  C, etc
Skill
Six sigma required strong statistical &  analytical knowledge
RED x   requires good technical  knowledge, engineering skills, common sense, and simple statistics to solve technical problems with statistical confidence
 
 

An Attribute Gage study is a study that studies the bias and repeatability of an attribute measurement system. It is useful to decide which sources are responsible for the variation of the measurement data. The best one of these is a go/no go gage. This gage basically tells you if the part passes or it fails. There are only two likely outcomes. Other attribute measurement systems can have many categories such as very good, good, poor and very poor
 
What is an attribute agreement analysis?
 
Attribute Agreement Analysis (or Attribute MSA) is one of the tools within MSA, used to estimate your measurement system when attribute (qualitative) measurements are involved. With this we can confirm that measurement error is at an acceptable level before conducting data analysis
 
Attribute Agreement Analysis is the type of Measurement System Analysis (MSA) that is used to measure how well an attribute (discrete) measurement system is working. Gage R&R is the type of Measurement System Analysis (MSA) that is used to measure how well a variable (continuous) measurement system is working.
 
The Attribute Agreement Analysis study can be set up in a similar way as a regular Gauge R&R study. A number of parts are selected from the process, and are gage by two or more operators. This doesn’t just relate to Pass/Fail type assessments, such as with Go/No-Go type gauges, but it can also be used to test the reliability of operators where they make assessment on a rating scale.
 
When to Work with Attribute Agreement Analysis ? 
 
Work with Attribute Agreement Analysis if you aim at doing a Gage R&R (MSA) for a test/measurement that does NOT lead to results you could gage with a measurement instrument. we want it if the results are qualitative. Examples:
Visual quality control of parts. Examination of whether the cleaning was done well. Check whether a document is accessible. To Run the Analysis 
 
What is our objective to find out? Accuracy or Precision? Reproducibility or Repeatability? 
 
To Calculate Accuracy 
 
 Understand how well the measurement system comes to the same results as per the “standard”.


 
Calculate % R & R 
 
Shows how exactly the different appraisers agree about results and how precisely one and the same appraiser comes to the same results when measuring multiple times. 
Total % R&R defines the level of agreement within/ between appraisers and a standard Total %R&R should be 100% (when the study conditions are different from reality every result below 100% will lead to a measurement system not worth trusting) If the Total %R&R is less than 100% examine the results to see if this is a problem of repeatability, reproducibility or both