Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
  • G06Q10/063—Operations research, analysis or management
  • G06Q10/0633—Workflow analysis
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
  • G06Q10/063—Operations research, analysis or management
  • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
  • G06Q10/06316—Sequencing of tasks or work

Definitions

• the present technology relates to the automation of processes which may be complex or frequently changed. It is particularly applicable to complex advanced engineering where components may need to go through a number of operations which are independent and where judgement or human intervention is required so that the process is not linear and may vary from one execution to the next.
• An issue with automating real-world processes is that whilst the mere automation may be straightforward, it may be a difficult process to identify all the workflows before automation or coding can begin and be handed over to programmers.
• problems frequently arise and debugging is complex as the programmers are divorced from the original process. It is well known for IT implementation projects to over-run and last for years.
• the documentation of the process may be a major task taking several months or even years and the programmers cannot begin until this is complete, often leading to long delays before any benefits of automation can be seen.
• the initial process is rarely complete and accurate or even if it is the process may change and this requires going around the whole cycle again.
• both the initial process and the coding process may introduce errors and if an automated process fails it may be complex to debug.
• the programmers are many steps removed from the process and it is problematic to relate issues in coding to the process and correct.
• CCM DocuSign's Contract Lifecycle Management
• Such a tool has pre-built functionality for allowing development of workflow implementations using a visual interface where each of the various actions, for each of the possible actors (sales, legal, etc) and the sequence of steps (flowcharts) are visually displayed, for each of the possible paths through the workflow for the complex process.
• the software code for carrying out the steps/actions is also embedded within the tool.
• the technology disclosed herein provides a method of automating a process to process an object and/or perform a task comprising: identifying a higher level workflow related to the process and encoding the higher level workflow in a higher level workflow program document, which higher level workflow program document is both machine interpretable and presented and editable in human-intelligible form, the higher level workflow program document identifying: a set of actors who perform actions and/or make decisions, wherein the set of actors comprises one or more human operators , units within an organisation, machine-implemented tasks or a combination thereof, and wherein the actors are identified by human-intelligible labels; a sequence of action steps, each action step having an associated actor and one or more expected outcomes, wherein the action steps are identified by human-intelligible labels and comprises taking a decision and/or progressing processing of an object or task, wherein the action steps optionally include complex action steps definable by a lower level workflow; an identifier of a next step for each expected outcome, wherein a next step may include
• the method further comprises notifying an operator upon raising an exception or upon detection of an error while the workflow program documents are running.
• the sequence of action steps comprises determining a state of an object or task to determine a next step.
• determining a state of an object or task comprises determining that a component part for the object is received, determining that the object has been assembled, determining that the object has passed quality check, determining that a document has been generated, determining that a document has been reviewed.
• the next action step comprises passing the object to assembly, passing the object to quality assurance, passing the object to completion, sending a document to a predetermined actor for review, or sending a document to a predetermined actor for completion.
• the determining a state of an object or task is performed by a human operator, a software function and/or at least in part by an Al module.
• the set of actors comprises one or more of machine processes, fabrication, machining, finishing, surface treatment, electronics, assembly, machining quality control, or a combination thereof.
• the sequence of action steps comprises one or more of cut blank, polish, surface treat, check tolerances, install PCB, test sensors, or a combination thereof.
• the set of actors comprises one or more of sales, document preparation, legal, procurement, fulfilment, or a combination thereof.
• the sequence of action steps comprises one or more of generate pricing, check compliance, check lead times, send to customer, or a combination thereof.
• the workflow program document is arranged in tabular form in a table.
• the method further comprises: defining the sequence of action steps by a series of rows in the table; and identifying, for each row: an actor from the set of actors in a first column; an action step from the sequence of action steps in a second column, the actor identified in the first column being associated with the action step; an expected outcome associated with the action step in a third column; and an identifier of a next step for the expected outcome identified in the third column in a fourth column.
• one or more rows of the table each comprises a plurality of action steps.
• action steps defined in the lower level workflow program document comprises a constrained action step corresponding to a single action defined in the lower level workflow program document, or an unconstrained action step corresponding to a series of operation steps defined in a separate program document outside the workflow program documents, or a combination thereof.
• the method further comprises assigning an authority level for each actor indicating an extent to which the actor is authorised to edit the higher level and/or lower level workflow program document.
• the object or task to be processed is defined in an object or task definition document outside the workflow program documents, wherein the object or task definition document defines a set of parameters and/or attributes associated with the object or task.
• the associated set of parameters and/or attributes is defined in a high-level computing language and editable only by a predetermined actor or group of actors.
• the higher level workflow program document further identifies a predetermined communication format associated with each series of action steps, wherein when the identifier of a next step for an expected outcome of a first sequence of action steps associated with a first actor identifies a second sequence of action steps associated with a second different actor, the method further comprises, notifying the second actor in the predetermined communication format to perform the second sequence of action steps.
• each human-intelligible label identifying an actor or an action step comprises words, symbols and/or numbers carrying their common everyday meaning and comprehensible by a human operator.
• the method further comprises identifying, by a label parser, an inconsistency in the human-intelligible labels.
• the method further comprises the label parser providing a suggestion for an inconsistent label.
• the method further comprises, upon raising an exception, generating a report identifying one or more issues that caused the exception.
• the method further comprises providing in the report a plurality of options for resolving the exception, the plurality of options comprising one or more of modifying a higher level workflow program document, modifying a lower level workflow program document, modifying a frequently-used workflow program document, including a new lower level workflow in a lower level workflow program document, manually bypassing a workflow or an action step, or manually adjusting a workflow or an action step.
• the method further comprises assigning a priority to each of the plurality of options for resolving the exception.
• the plurality of options is selectable, the method further comprising, upon an option being selected, presenting a part of the workflow program document on an interface when the one or more issues that caused the exception relates to the part of a workflow program document.
• the method further comprises generating one or more editable patch comprising one or more element of a workflow program document corresponding to the identified one or more issues that caused the exception.
• the method further comprises implementing a machine learning algorithm for monitoring the running of the workflow program documents so as to generate the plurality of options and/or the one or more editable patch.
• the method further comprises, upon raising an exception in relation to a first sequence of action steps, notifying a first actor associated with the first sequence of action steps, or a predetermined human operator assigned to the first sequence of action steps, or a predetermined Al module, or a combination thereof.
• the method further comprises providing for selection a plurality of editable workflow program document elements for compiling a final workflow program document.
• the method further comprises providing a recommendation for an editable workflow program document element for compiling the final workflow program document.
• the lower level workflow program document comprises a plurality of tiers of lower level workflows.
• the method further comprises assigning each lower level workflow in the lower level workflow program document to a tier based on a frequency of use thereof.
• the technology disclosed herein provides a method of automating a process to process a task or an object comprising: defining elements of the process in one or more human-intelligible and editable and machine interpretable workflow program documents, the workflow program documents each including a plurality of actors who perform actions or take decision, a sequence of action steps each associated with an actor and having at least one expected outcome and a corresponding next step for each expected outcome, and wherein the action steps may include a first type of action further defined within the workflow program documents and a second type of action implemented by a computer according to code defined other than in said workflow program documents; and executing the process by a processor running the code defined by the workflow program documents, wherein if an exception is detected in the processing of a task or object according to the code, the exception is passed to a supervisory function to perform a remedial action, wherein the available remedial actions include individually modifying the task or object to be processed or on the fly patching or modifying of the workflow program documents, wherein the modified workflow program documents are interpreted or
• the supervisory function can take a human intervention to deal with the individual case and/or can decide to modify the workflow to handle such events in future without causing an exception or perhaps partially modify the process.
• This approach goes fundamentally against the general principle of operation of almost all IT systems in common use on the planet today by giving non-specialists the ability to reprogram or patch a potentially highly complex enterprise-level workflow "on the fly" without the usual processes and safeguards. This is in part made possible because of the novel architecture where if the modified workflow causes problems or unintended consequences, the other systems and building blocks are unaffected and should keep running and any new exceptions will be handed back to the supervisory function.
• the tabular form may be stored conveniently in a CSV file or Excel spreadsheet and manipulated using existing tools (with Copy and Paste) for editing and working with such tables to generate workflow programs in an environment a non-specialist programmer user may be familiar with.
• an exception is passed to a supervisory function to perform a remedial action wherein the available remedial actions include individually modifying the task or object to be processed or on the fly patching or modifying of the workflow program documents, wherein the modified workflow program documents are interpreted or re-compiled whereby the processor subsequently executes a modified process according to the modified document.
• the method may include defining a sequence of steps including at least one action step which is dependent on the outcome of another step performed by a different actor and recording a dependency condition and separately defining an action step to be performed by the different actor which, if executed successfully, will satisfy the dependency condition.
• a first user who is familiar with the overall process workflow but need not be conversant with the full details of each task or object being operated on can define and edit or manage exceptions in the overall workflow.
• a second user who may be familiar with the details of some objects or tasks but need not know the full details of the overall workflow can edit the object definitions. For example, if it is found that an additional variable may be helpful to track a particular component it can be added without needing to re-encode the overall workflow.
• the method provides for the development and use of a new tool for the automation of a complex workflow, which does not suffer from the problems identified above with currently available visual representation language tools.
• the resulting particular workflow that has just been created for a new process to be automated can be represented simply in the workflow program document, due to the combination of the existing visual representation tool with the new workflow program document and the new associated linear programming used to process the workflow program document.
• the technology disclosed provides a method of encoding a program defining a workflow for implementing a process, the method comprising: defining a sequence of actions by a series of first rows in a table; and for each row identifying:
• the method further comprises, for each first row, identifying in a fifth column one or more dependency conditions for a corresponding action step identified in the second column, wherein execution of the corresponding action step is conditional on the dependency condition being satisfied.
• the method further comprises defining a further action in a second row, wherein execution of the second row results in the dependency condition being satisfied
• the table is stored in a CSV file or a spreadsheet.
• one or more first rows each comprises a plurality of action steps.
• an action step comprises determining a state of an object of the process to determine a next step.
• determining a state of the object comprises determining that a component part for the object is received, determining that the object has been assembled, determining that the object has passed quality check, determining that an object document has been generated, determining that an object document has been reviewed.
• the next step comprises passing the object to assembly, passing the object to quality assurance, passing the object to completion, sending the object document to a predetermined actor for review, or sending the object document to a predetermined actor for completion.
• an action step comprises one or more of cut blank, polish, surface treat, check tolerances, install PCB, test sensors, or a combination thereof.
• an actor comprises one or more of sales, document preparation, legal, procurement, fulfilment, or a combination thereof.
• an action step comprises one or more of generate pricing, check compliance, check lead times, send to customer, or a combination thereof.
• an action step comprises at least one constrained action step corresponding to a single action defined within the program.
• an action step comprises at least one unconstrained action step corresponding to a series of operation steps defined in a separate program document outside the program.
• the method further comprises assigning an authority level for each actor indicating an extent to which the actor is authorised to edit the program.
• an object of the process is defined in an object definition document separate from the program, wherein the object definition document defines a set of parameters and/or attributes associated with the object.
• the associated set of parameters and/or attributes is defined in a high-level computing language and editable only by a predetermined actor or group of actors.
• each row of the table is identified by a human-intelligible label
• each human-intelligible label comprises words, symbols and/or numbers carrying their common everyday meaning and comprehensible by a human operator.
• the method further comprises identifying, by a label parser, an inconsistency in the human-intelligible labels, and providing a suggestion to resolve the inconsistency.
• the method further comprises defining an exception path in a third row, the third row being identifiable as a next step of a first row in the table when the expected outcome of first rows meets a predetermined condition.
• execution of the exception path generates a report identifying the predetermined condition.
• the method further comprises providing in the report a plurality of options for resolving the predetermined condition, the plurality of options comprising one or more of modifying a first row, modifying one or more of the first, second, third or fourth columns of a first row, defining a new row, manually bypassing a first row, or manually adjusting a first row.
• the method further comprises assigning a priority to each of the plurality of options for resolving the predetermined condition.
• the method further comprises generating one or more editable patch comprising one or more element of the first row with the undesirable outcome.
• the method further comprises implementing a machine learning algorithm for monitoring the running of the program so as to generate the plurality of options and/or the one or more editable patch.
• execution of the exception path generates a notification to a predetermined actor associated with the first row with the predetermined condition and/or a predetermined Al module.
• the method further comprises providing an interface for receiving inputs from an operator, wherein the inputs comprise selecting a section of the table, copying and pasting a section of the table, dragging and dropping a section of the table, and/or modifying a section of the table.
• the technology disclosed provides a computer program or computer program product comprising information arranged for tabular representation comprising a sequence of rows corresponding to a sequence of actions to perform the process, each row containing information identifying:
• the technology disclosed provides a computer implemented method of executing a process comprising parsing a workflow program document to read a sequence of actions from a sequence of rows, wherein an identifier of actor associated with each action is read from a first column, an identifier of an action to be executed is read from a second column, expected outcomes are identified in a third column and a next step for each expected outcome is identified from a fourth column.
• the technology disclosed provides a method of automating a process to process a task or an object comprising: defining elements of the process in one or more human-intelligible and editable and machine interpretable workflow program documents, the workflow program documents each including a plurality of actors who perform actions or take decision, a sequence of action steps each associated with an actor and having at least one expected outcome and a corresponding next step for each expected outcome and wherein the action steps are recorded in sequential form and have an option to include one or more dependencies on other actions or actors; executing the process by a processor running the code defined by the workflow program documents wherein in executing the sequential actions, optional dependencies are evaluated and action steps are deferred notwithstanding their sequence in the documents if dependencies are not satisfied.
• the method further comprises defining a first sequence of action steps performed by a first actor, wherein execution of at least one action step of the first sequence is dependent on the outcome of an action step of a second sequence of action steps performed by a second actor, and recording a dependency condition with the first sequence of action steps.
• the dependency condition of the first sequence is satisfied and the at least one action step of the first sequence is executed.
• an action step comprises determining a state of an object of the process to determine a next step.
• determining a state of the object comprises determining that a component part for the object is received, determining that the object has been assembled, determining that the object has passed quality check, determining that an object document has been generated, determining that an object document has been reviewed.
• the next step comprises passing the object to assembly, passing the object to quality assurance, passing the object to completion, sending the object document to a predetermined actor for review, or sending the object document to a predetermined actor for completion.
• an action step comprises one or more of cut blank, polish, surface treat, check tolerances, install PCB, test sensors, or a combination thereof.
• an actor comprises one or more of sales, document preparation, legal, procurement, fulfilment, or a combination thereof.
• an action step comprises one or more of generate pricing, check compliance, check lead times, send to customer, or a combination thereof.
• an action step comprises at least one constrained action step corresponding to a single action defined in the workflow program document.
• an action step comprises at least one unconstrained action step corresponding to a series of operation steps defined in a separate program document outside the workflow program documents.
• an object of the process is defined in an object definition document separate from the workflow program documents, wherein the object definition document defines a set of parameters and/or attributes associated with the object.
• the associated set of parameters and/or attributes is defined in a high-level computing language and editable only by a predetermined actor or group of actors.
• each sequence of action steps is identified by a human-intelligible label
• each human- intelligible label comprises words, symbols and/or numbers carrying their common everyday meaning and comprehensible by a human operator.
• the method further comprises identifying, by a label parser, an inconsistency in the human-intelligible labels, and providing a suggestion to resolve the inconsistency.
• the method further comprises defining an exception sequence, wherein when the at least one expected outcome of a sequence of action steps is an undesirable outcome, the corresponding next step for the undesirable outcome routes to the exception sequence.
• execution of the exception sequence generates a report identifying the undesirable outcome.
• the method further comprises providing in the report a plurality of options for resolving the undesirable outcome, the plurality of options comprising one or more of modifying the task or object to be processed, applying a patch to a workflow program document while the code is running, modifying a workflow program document to be re-compiled whereby the processor subsequently executes the code with the modified workflow program document.
• the method further comprises assigning a priority to each of the plurality of options for resolving the undesirable outcome.
• the method further comprises generating one or more editable patch comprising one or more element of the first row with the undesirable outcome.
• the method further comprises implementing a machine learning algorithm for monitoring the running of the program so as to generate the plurality of options and/or the one or more editable patch.
• the technology provides a method of automating a process to process a task or an object comprising: defining elements of the process in one or more human-intelligible and editable and machine interpretable workflow program documents, the workflow program documents each including a plurality of actors who perform actions or take decision, a sequence of action steps each associated with an actor and having at least one expected outcome and a corresponding next step for each expected outcome and wherein the action steps are recorded in sequential form and have an option to include one or more dependencies on other actions or actors; recording in one or more separately editable human-intelligible and machine interpretable object or task definition documents definitions of tasks or objects referenced in the workflow program documents by human-intelligible labels wherein the object or task definition documents include parameters and attributes for each task or object; executing the process by a processor running the code defined by the workflow program documents wherein in
• the method further comprises defining a first sequence of action steps performed by a first actor, wherein execution of at least one action step of the first sequence is dependent on the outcome of an action step of a second sequence of action steps performed by a second actor, and recording a dependency condition with the first sequence of action steps.
• the dependency condition of the first sequence is satisfied and the at least one action step of the first sequence is executed.
• an action step comprises determining a state of an object of the process to determine a next step.
• determining a state of the object comprises determining that a component part for the object is received, determining that the object has been assembled, determining that the object has passed quality check, determining that an object document has been generated, determining that an object document has been reviewed.
• the next step comprises passing the object to assembly, passing the object to quality assurance, passing the object to completion, sending the object document to a predetermined actor for review, or sending the object document to a predetermined actor for completion.
• an actor comprises one or more of machine processes, fabrication, machining, finishing, surface treatment, electronics, assembly, machining quality control, or a combination thereof.
• an action step comprises one or more of cut blank, polish, surface treat, check tolerances, install PCB, test sensors, or a combination thereof.
• an actor comprises one or more of sales, document preparation, legal, procurement, fulfilment, or a combination thereof.
• an action step comprises one or more of generate pricing, check compliance, check lead times, send to customer, or a combination thereof.
• an action step comprises at least one constrained action step corresponding to a single action defined in the workflow program documents.
• an action step comprises at least one unconstrained action step corresponding to a series of operation steps defined in a separate program document outside the workflow program documents.
• an object of the process is defined in an object definition document separate from the program, wherein the object definition document defines a set of parameters and/or attributes associated with the object.
• the associated set of parameters and/or attributes is defined in a high-level computing language and editable only by a predetermined actor or group of actors.
• each sequence of action steps is identified by a human-intelligible label
• each human- intelligible label comprises words, symbols and/or numbers carrying their common everyday meaning and comprehensible by a human operator.
• the method further comprises identifying, by a label parser, an inconsistency in the human-intelligible labels, and providing a suggestion to resolve the inconsistency.
• the method further comprises defining an exception sequence, wherein when the at least one expected outcome of a sequence of action steps is a predetermined undesirable outcome, the corresponding next step for the predetermined undesirable outcome identifies the exception sequence.
• execution of the exception sequence generates a report identifying the predetermined undesirable outcome.
• the plurality of options comprising one or more of modifying the task or object to be processed, applying a patch to a workflow program document while the code is running, modifying a workflow program document to be re-compiled whereby the processor subsequently executes the code with the modified workflow program document.
• the method further comprises assigning a priority to each of the plurality of options for resolving the predetermined undesirable outcome.
• the method further comprises generating one or more editable patch comprising one or more element of the first row with the predetermined undesirable outcome.
• the method further comprises implementing a machine learning algorithm for monitoring the running of the program so as to generate the plurality of options and/or the one or more editable patch.
• the technology provides a program document encoding a process comprising: one or more workflow program documents, each workflow program document defining elements of the process and each workflow program document defining a plurality of actors who perform actions or take decision, a sequence of action steps each associated with an actor and having at least one expected outcome and a corresponding next step for each expected outcome and wherein the action steps are recorded in sequential form and have an option to include one or more dependencies on other actions or actors; and one or more object or task definition documents recording definitions of tasks or objects referenced in the one or more workflow program documents by a corresponding human-intelligible label, wherein the one or more object or task definition documents include parameters and attributes for each task or object.
• the technology provides a method of executing the program document mentioned in the preceding paragraph, comprising running, by a processor, the code defined by the one or more workflow program documents, wherein the sequential actions, tasks or objects are handled with reference to human-intelligible labels, and wherein the one or more workflow program documents are editable by a first interface by a first user during execution of the program document and/or in response to an exception occurring in the workflow, and wherein the object or task definition documents are editable by a second interface by a second user independent of the execution of the workflow program documents.
• the present technology provides a computer implemented tool for automating a process, comprising: a) a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) first software programming code programmed to filter the rows and columns of the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and c)an visual programming framework for displaying on a user interface a visual representation of a flowchart of a process to be automated, using pre-built visual representations of workflow components, and wherein the visual programming framework also includes second software program code for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the filtering software, interacts with the workflow components of the visual programming framework to carry out automated tasks according to the human readable labels
• a path through a portion of the process starts with a first label in a first column of the workflow program document, designating a name for the portion of the process, and, along the path, across the columns, has a label in an actor column identifying a particular actor for carrying out the portion of the process, a label in an action step column identifying a particular action step to be carried out by the actor as part of the portion of the process, and a label in an outcome column identifying an outcome of the portion of the process, and a next step label indicating a first label for a next portion of the process to be carried out.
• one of the action steps identified in the action step column is a function which is carried out under the direction of the execution of the software programming included in the visual programming framework.
• one of the action steps identified in the action step column is a function which is carried out under the direction of the execution of the software programming code developed in a linear programming language separate from the visual programming framework.
• the software programming code at b) is developed such that a first filter is designed to identify all rows having a first label matching a first value, and a second filter is designed to identify all rows which are output from the first filter and which have a label matching a second value.
• another column has a label indicating an output of an action step, and which indicates a value of one of a plurality of outputs of the action step.
• the linear programming language is C Sharp.
• the existing visual programming framework is the Contract Lifecycle Management product from DocuSign.
• the workflow program document is a spreadsheet.
• one of values of the next step label is a value indicating an exception, meaning that a corresponding action step for a current portion of the process has failed to complete, and, the next step label indicates a next portion of the process, following the current portion of the process, to be an exception handling portion.
• another column has a label indicating an outcome of the portion of the process, wherein the label indicates such outcome of the portion of the process as being a success or a failure.
• the tool prompts the actor to provide input to the tool, to complete the action step.
• the prompt is generated by software code included in the existing visual programming framework.
• the prompt is generated by software programming code developed in the linear programming language.
• the value of the output of the action step is selected by the actor amongst a choice of a plurality of such values.
• At least one of the first and second software program code is user editable, at least in part.
• the present technology provides a method of developing a tool for automating a process, the method comprising steps of: a) developing a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) developing software programming code in a linear programming language, programmed to filter the rows and columns of the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and cjselecting an existing visual programming framework for displaying on a user interface a visual representation of a flowchart of a process to be automated, using pre-built visual representations of workflow components, and the existing visual programming framework also includes the software programming for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the filtering software, directs the workflow components
• the present technology provides a method of using a tool for automating a process, the method comprising a) using a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) using software programming code developed in a linear programming language, programmed to filter the rows and columns of the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and cjusing an existing visual programming framework for displaying on a user interface a visual representation of a flowchart of a process to be automated, using pre-built visual representations of workflow components, and the existing visual programming framework also includes the software programming for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the filtering software, directs the workflow components of the visual programming framework
• the present technology provides a computer implemented tool for automating a document handling process, comprising: a) a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the document handling process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) first software program code, programmed to process the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and c)a document handling visual programming framework for displaying on a user interface a visual representation of a user-editable flowchart of a process to be automated, using pre-built visual representations of workflow components, and wherein the visual programming framework also includes second program code for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the first software program code, interacts with the workflow components of the visual programming framework to carry out automated document handling
• a path through a portion of the document handling process starts with a first label in a first column of the workflow program document, designating a name for the portion of the process, and, along the path, across the columns, has a label in an actor column identifying a particular actor for carrying out the portion of the process, a label in an action step column identifying a particular action step to be carried out by the actor as part of the portion of the process, and a label in an outcome column identifying an outcome of the portion of the process, and a next step label indicating a first label for a next portion of the process to be carried out.
• one of the action steps identified in the action step column is a function which is carried out under the direction of the execution of the software programming included in the document handling visual programming framework.
• one of the action steps identified in the action step column is a function which is carried out under the direction of the execution of the software programming code developed in a linear programming language separate from the document handling visual programming framework.
• the software programming code at b) is developed such that a first filter is designed to identify all rows having a first label matching a first value, and a second filter is designed to identify all rows which are output from the first filter and which have a label matching a second value.
• another column has a label indicating an output of an action step, and which indicates a value of one of a plurality of outputs of the action step.
• the linear programming language is C Sharp.
• the existing document handling visual programming framework is the Contract Lifecycle Management product from DocuSign.
• the workflow program document is a spreadsheet.
• one of values of the next step label is a value indicating an exception, meaning that a corresponding action step for a current portion of the process has failed to complete, and, the next step label indicates a next portion of the process, following the current portion of the process, to be an exception handling portion.
• another column has a label indicating an outcome of the portion of the process, wherein the label indicates such outcome of the portion of the process as being a success or a failure.
• the tool prompts the actor to provide input to the tool, to complete the action step.
• the prompt is generated by software code included in the existing visual programming framework.
• the prompt is generated by software programming code developed in the linear programming language.
• the value of the output of the action step is selected by the actor amongst a choice of a plurality of such values.
• one value of a label inserted into the action step column is an Add Document value, indicating an action step which takes place when a document is being added to a document handling system.
• the present technology provides a method of developing a tool for automating a document handling process, the method comprising steps of: a) developing a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the document handling process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) developing software programming code in a linear programming language, programmed to filter the rows and columns of the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and cjselecting an existing document handling visual programming framework for displaying on a user interface a visual representation of a flowchart of a process to be automated, using pre-built visual representations of workflow components, and the existing visual programming framework also includes the software programming for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the filtering software
• the present technology provides a method of using a tool for automating a document handling process, the method comprising a) using a workflow program document comprising rows and columns, where each row represents one of a plurality of paths through a portion of the document handling process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) using software programming code developed in a linear programming language, programmed to filter the rows and columns of the workflow program document so as to direct a portion of the process along one of the plurality of paths to an outcome, depending on the content of the human readable labels in the columns; and cjusing an existing document handling visual programming framework for displaying on a user interface a visual representation of a flowchart of a process to be automated, using pre-built visual representations of workflow components, and the existing visual programming framework also includes the software programming for carrying out functionality associated with such visual representations of workflow components, wherein the workflow program document, through the operation of the filtering software, directs the workflow
• the present technology provides a computer implemented method for identifying patterns in the automation of one or more processes, comprising: a) recording workflow steps in a log document, the log document including data describing an execution history of processing of at least one workflow program document, where the workflow program document comprises rows and columns, where each row represents one of a plurality of paths through a portion of a process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process; b) processing the log document with a machine learning algorithm to identify at least one pattern suggesting an edit to a workflow program document to be modified; cjbased on the identified pattern, suggesting an edit to the workflow program document to be modified, wherein the edit comprises at least one of: a.
• a sequence of steps to perform a further component of an existing process to be automated b. a sequence of steps to perform a component of a further process to be automated; c. an identification of similar sequences of steps to validate differences; d. a suggested modification of one or similar sequences for consistency. e. an identification of a possible error in a sequence of steps; or f. a suggestion of a template for creation of future workflow program documents.
• a path through a portion of the process starts with a first label in a first column of the workflow program document, designating a name for the portion of the process, and, along the path, across the columns, has a label in an actor column identifying a particular actor for carrying out the portion of the process, a label in an action step column identifying a particular action step to be carried out by the actor as part of the portion of the process, and a label in an outcome column identifying an outcome of the portion of the process, and a next step label indicating a first label for a next portion of the process to be carried out.
• software programming code is developed to process a workflow program document such that a first filter is designed to identify all rows having a first label matching a first value, and a second filter is designed to identify all rows which are output from the first filter and which have a label matching a second value.
• another column has a label indicating an output of an action step, and which indicates a value of one of a plurality of outputs of the action step.
• the workflow program document is a spreadsheet.
• one of values of the next step label is a value indicating an exception, meaning that a corresponding action step for a current portion of the process has failed to complete, and, the next step label indicates a next portion of the process, following the current portion of the process, to be an exception handling portion.
• the step of suggesting an edit provides to a user one or more suggested modifications to the workflow program document for the process, based on the exception.
• the machine learning algorithm receives input runtime data regarding the occurrence of at least one exception, and provides information suggesting an edit to a corresponding workflow program document for the process, based on such runtime data.
• the machine learning algorithm receives input runtime data concerning execution times and provides information suggesting an edit to a corresponding workflow program document for a process, based on such runtime data.
• one or more of the processes is a document handling process.
• another column has a label indicating an outcome of the portion of the process, wherein the label indicates such outcome of the portion of the process as being a success or a failure.
• the tool prompts the actor to provide input to the tool, to complete the action step.
• the value of the output of the action step is selected by the actor amongst a choice of a plurality of such values.
• the method provides for the identification of patterns in the automation of a process, by applying a machine learning algorithm to a log file storing historical data regarding the processing of a workflow program document. This results in very useful information being provided as output, which is used to edit a workflow program document to take advantage of past knowledge/information to provide better workflow automation for current and future process automation work.
• the present technology provides a computer program product, on a computer readable storage medium, for, when executed on a computer system, directing the computer system to carry out the method of any of the preceding aspects.
• the present technology provides a computer system comprising means adapted for carrying out the method according to any of the preceding aspects.
• Fig. 1 shows an exemplary conventional method of automating complex processes
• Fig. 2 shows an exemplary method of automating complex processes according to an embodiment
• Fig. 3A shows the left half of an exemplary workflow program document of a manufacturing process according to an embodiment
• Fig. 3B shows the right half of the exemplary workflow program document of Fig. 3A according to an embodiment
• Fig. 4 shows schematically a workflow based on a workflow program document according to an embodiment
• Fig. 5 shows an example of workflow routing to completion based on the workflow program document of Figs. 3A and 3B;
• Fig. 6A shows the left half of an exemplary workflow program document of a document signing process according to an embodiment
• Fig. 6B shows the right half of the exemplary workflow program document of Fig. 6A according to an embodiment
• Fig. 7 shows an example of workflow routing to completion based on the workflow program document of Figs. 6A and 6B;
• Fig. 8 shows an example of workflow routing to exception based on the workflow program document of Figs. 3A and 3B;
• Fig. 9 shows an exemplary exception handling interface according to an embodiment
• Fig. 10 shows an exemplary complex approval process
• Fig. 11 shows an exemplary workflow program document for the complex approval process of Fig. 10 according to an embodiment
• Fig. 12 shows a block diagram of a three part architecture for implementing the tool, according to an embodiment
• Fig. 13 shows a flowchart for a method of developing the tool, according to an embodiment
• Fig. 14 shows a flowchart for a method of using the tool, according to an embodiment
• Fig. 15 shows a flowchart for a method of identifying a pattern using a machine learning algorithm, according to an embodiment.
• automation of a complex process begins with a planning stage in which all possible actions involved in the process and all possible ways of routing from to and from each action are identified and documented as one or more workflows.
• the workflows of the identified actions and corresponding routes is generally documented as a complex flow diagram with many branches, conditions, options and possible outcomes.
• the complex flow diagram may then be programmed during an implementation stage, often by a contracted programmer outside of the organisation, in a labour-intensive and time-consuming iterative process.
• the workflow program is then tested, debugged, revised and re-tested until it is running as expected, and finally deployed at a deployment stage. If at any point during runtime, the workflow program encounters an error, the workflow program is sent back to the planning stage and the process is reviewed for possible changes, updates and corrections.
• Fig. 1 This conventional approach of automating a complex process, such as a precision manufacturing process for an article in a factory, is illustrated Fig. 1.
• the method begins at S101.
• components of the complex process are reviewed, for example by a supervisor of the process or each of a plurality of supervisors of each branch of the process, and documented.
• a component may for example be a workflow related to a given branch of the process, such as selection of a part in a manufacturing process.
• the document is reviewed at S103 by an authorised person, for example a manager, who approves (or rejects) the document at S104 and forwards it on for implementation.
• the document is handed to a program designer to design a program for automating the documented process, then, generally, a programming team develops the detailed code at S106 based on the design.
• the program is tested and debugged at S107 to determine, at S108, whether the detailed code is performing as expected based on the document. After a number of testing and debugging cycles, if the program does not perform as desired, the document is sent back to S202 to be reviewed again and optionally redocumented. If the program performs as desired according to the documented process, the program is sent for deployment.
• the program code is installed, e.g. on a computing system of the factory, and the installed code is run at Slid on the computing system to execute the process Sill.
• a supervisor or supervisory function may determine at S112 whether the program is performing as expected, e.g. the process has been executed to completion, or if the execution of the process has terminated with an error. If the execution of the process is not performing as expected, the program and the documented process are sent back to S102 for review and optionally redocumented. If the execution of the process is performing as expected, the supervisor or supervisory function may further determine at S113 whether there has been any changes in the process since the process was documented.
• the documented process is sent back to S102 for review and redocumented. If it is determined that there has been no changes to the process, the supervisor or supervisory function may further determine at S114 if at any point during the execution of the process it has met any unexpected conditions or exceptions, for example whether a particular workflow is excluded. If it is determined that one or more unexpected conditions or exceptions have occurred, the documented process is sent back to S102 for review and optionally redocumented. If it is determined that there has been no unexpected conditions or exceptions, the supervisor or supervisory function may further determine at S115 if the execution of the process has returned any unexpected or undesired outcome, for example if the execution of the process has terminated before the manufacturing of the article is completed.
• the documented process is sent back to S102 for review and optionally redocumented. If it is determined that there has been no unexpected or undesired outcome, the method returns to Slid and the program code is again run, and the process is again executed.
• the conventional approach requires that the documented process and the program code be sent back to the planning stage whenever the programming or the execution of the program code encounters any errors or unexpected exceptions. Since the planning, implementation and deployment stages are decoupled from each other, any errors or unexpected exceptions may need to be independently identified by both a supervisor of the factory and the programming team, and then the code is updated or debugged by the programming team and tested before redeployment.
• the present technology provides a radically different approach in which the planning and implementation stages are combined and simplified, in that a workflow program document can be deployed even when it is only partially complete. This is facilitated by a new workflow program architecture that allows continuous editing and updating of the workflow program document while it is deployed.
• the present approach instead of the conventional approach of decoupling the planning, implementation and deployment stages, the present approach combines the planning and implementation stages, and the combined planning and implementation stages are overlapped with the deployment stage.
• the present approach is exemplified in Fig. 2.
• Fig. 2 illustrates schematically a method of automating a complex process according to an embodiment.
• the method begins at S201 at the combined planning and implementation stage.
• an initial workflow program document 200 is created, which generally comprises a high (or top) level workflow with one or more optional low-level workflows, the high-level workflow and each optional low- level workflow is identified by a human-intelligible label and ends with a next-step label that identifies the label to be read next.
• the workflow program document may for example be stored in a tabular form, and it will be described in more detail below. Unlike the workflow program code from the example of Fig.
• the initial workflow program document created at S202 does not need to be complete, in that the initial workflow program document only requires as minimum the high-level workflow before it can be executed.
• the workflow program document 200 Once the workflow program document 200 is created, it can be deployed with minimal to no testing or debugging (although in practice it may be preferable to test the workflow program document 200 before deployment).
• the method begins at S203 with the selection of a start label.
• a start label may be the selection of a component part.
• the method proceeds to S204 when the workflow program document 200 is read to identify a sequence.
• a set of low-level workflows identified by the same label is referred to as a sequence.
• the high-level workflow is executed at S205, followed by a low-level workflow (if any) referenced in the high-level workflow at S206.
• the workflow ends with a nextstep label that indicates the next step to be executed.
• next-step label is read at S207, and at S208 it is determined if the next-step label indicates that the process has completed. If it is determined that the process has completed at S208, the method returns to S203 and a start label is selected to begin the process again. If it is determined that the process has not completed at S208, the method returns to S204 and the workflow program document 200 is read again to identify the next sequence to be executed as identified by the next-step label.
• the execution of a selected workflow may sometimes lead to an undesired outcome, for example a component part may fail a quality assurance check.
• the execution of this workflow ends with the next-step label "exception", which diverts the workflow to an exception handler S209 to resolve the undesired outcome.
• exception There may also be instances when an error occurs during the execution of the high- level workflow or a low-level workflow, causing the automated process to fail.
• the workflow that is executing when the error occurs is diverted to the exception handler S209.
• the exception handler S209 determines how the exception is to be resolved, for example by requesting a manual input from a human operator, or by selecting an appropriate response from a number of responses stored on a database based on the nature of the exception e.g. with the aid of an Al agent. Exception handling will be described in more detail below. If it is determined that the workflow program document 200 requires editing or updating, for example due to a change in the process or a missing element in a workflow, the method proceeds to S212 where the workflow program document is edited, then the method can again proceed to S203 at which a re-entry label is selected to direct the execution of the process back to the workflow where the exception occurs.
• the method proceeds to initiate an administrator rescue at S211.
• This may for example involve notifying an administratorthat a manual input is required and seek such manual input, or it may involve a more detailed diagnostic performed wholly or partially by an Al agent.
• a human administrator or an Al agent can for example inspect workflow variables, in particular to look for mistakes made by the actor(s) associated with the workflow that encounters the exception. If an error is discovered the error can be corrected on the fly as the workflow program document is being executed. For example, an actor may have misinterpreted the meaning of a request for approval leading to a failed outcome, and the administrator may manually mark the request as approved.
• the method can proceed to S203 at which a re-entry label is selected to direct the execution of the process back to the workflow where the exception occurs.
• the workflow program document 200 may be deployed without all workflows in the process having been incorporated therein, and an error or undesired outcome encountered during runtime can be resolved by the exception handler "on the fly" while the workflow program document is being executed without the need to return the workflow program document to the planning and implementation stage, and the automated process can resume at the point where the error or undesired outcome was detected once it is resolved.
• each group of workflows is identified by a label, and within the group or sequence each path corresponds to a different outcome that leads to a corresponding next step.
• the use of human-intelligible labelling of each sequence of workflow enables the workflow program document to be both machine-readable and human-intelligible, such that it can be equally easily managed and modified by anyone within the organisation (and not just a trained programmer).
• the segmentation of the different outcomes of different workflows enable each possible path to be uniquely identified in a uniform framework, enabling the workflow program document to be easily updated and expanded to include new low-level workflows.
• the low-level workflows are optional, in that the workflow program document can run with a high-level workflow alone without any or a complete set of low-level workflows, though it is generally preferred to include at least one low-level workflow in the workflow program document.
• the workflow program document can be configured to contain a placeholder for a low-level workflow for instances where a low-level workflow does not yet exist. With this approach, it is possible to run the workflow program document without having a complete set of low-level workflow, and a low-level workflow may be inserted at the placeholder during runtime when needed.
• the workflow program document may be encoded in a nonproprietary text format, allowing it to be edited without requiring any specialised tools. This enables the workflow program document to be portable between platforms (e.g. between different vendors) and allows non-specialist users to edit the document.
• the lower level workflows may alternatively or additionally be coded using specialist tools to allow for a higher level of customisation while still allowing the higher (top) level workflow to remain easy to interpret by an operator.
• the present approach is not specific to any particular industry, process or artefact and is universally applicable for automating any processes.
• the present approach is particularly advantageous for automating complex processes, in which changes to a given process are frequent and expectations for the automation to be completed in a short amount of time is high.
• Such challenges that are specific to complex processes can be addressed by the framework of the present approach due to its flexible nature, which allows early deployment by e.g. releasing a partially completed workflow program document.
• the dynamic nature of the framework enables changes to sequences and/or lower level workflows to be performed without disrupting the existing workflows in the workflow program document, thereby allowing a smoother release process.
• it can lead to significant implementation cost savings at the initial stages of automation as well as a reduction in long-term maintenance.
• FIGs. 3A and 3B show an exemplary workflow program document for a manufacturing process according to an embodiment.
• Fig. 3A illustrates the left half of the exemplary workflow program document while
• Fig. 3B illustrates the right half of the exemplary workflow program document.
• the exemplary workflow program document is shown in two parts to increase legibility, but it can be written, stored and read as a single document or two (or more) separate documents.
• the exemplary workflow program document includes a plurality of workflows, each workflow forming a sequence identified by a human-intelligible label (e.g. choosePart), and each sequence has an associated actor (e.g. Sales) that performs the workflow.
• Each sequence includes one or more paths each corresponding to a different outcome of the workflow (e.g. Success or Failure), and each outcome leads to a corresponding next step identified by a Next-Step Label.
• Each path comprises either a type 1 (constrained) action or a type 2 (unconstrained) action, or both, and each type of action comprises an action step and a corresponding output.
• additional conditions that differentiate one path from another within a workflow may be defined in a separate column e.g. "Condition”.
• a set of communication parameters associated with a workflow for communication between actors may be defined in a separate column e.g. "Comms", where for example such communication parameters may be specified with a code that identifies each set of communication parameters (e.g. in the form of templatised communication content) in a separate lookup table.
• additional information associated with a path may be defined in a separate column e.g. "Action Step 2 Options”.
• any dependencies that exist in a workflow may be defined in a separate column e.g. "Dependency”.
• a type 1 (constrained) action refers to an action step that requires a simple single-step action (referred to below as a "Simple Step") such as making a decision or routing to a different workflow.
• a simple Step such as making a decision or routing to a different workflow.
• the action step “Approval” requires a simple single-step action of either approval or rejection.
• a type 2 (unconstrained) action refers to an action step that requires a more complex multi-step action and/or execution of a sub-routine (e.g. programming that is outside of the workflow program document)(referred to below as a "Complex Step”).
• the action step "Create Certificate of Quality” diverts the workflow to a sub-routine to create a certificate of quality.
• the exemplary workflow program document is recorded in tabular form as a spreadsheet.
• a single line of the spreadsheet represents a path which describes a unique combination of high-level workflow, low-level workflow, as well as the inputs, outputs and conditions of these workflows.
• a sequence is a collection of paths having the same label. The combination of paths that defines a sequence may change depending on the evaluation of the condition.
• each workflow is identified with a machine-readable yet human-intelligible label that comprises texts, symbols or numbers that carry their normal everyday meaning, such that a workflow can be easily located, and more importantly any errors can be easily identified, by both a human operator and a software or Al tool.
• each actor, action step, condition, option, dependency, output and/or outcome are also recorded using human-intelligible labels.
• workflow program document By configuring a workflow program document into a uniform framework, segmenting each workflow into paths corresponding to different outcomes, and identifying each workflow using human-intelligible labels, new workflows and/or new paths may be inserted into the workflow program document straightforwardly without requiring specialist knowledge.
• segmentation of the workflows and paths means that modification, addition or deletion of a workflow or a path does not stop or immediately affect the execution of the workflow program document, such that these modification, addition or deletion can be made "on the fly" while the workflow program document is running.
• the workflow program document can be updated, or errors therein can be corrected, during execution without interrupting the process.
• a process is segmented according to actors, with a dedicated route for each actor.
• the present approach differs from the conventional approach in that different labels may be assigned to a given route associated with the same actor, for example to differentiate different portions of a timeline of the given route. For example, referring to Figs. 3A and 3B, the labels choosePart and sendToSales both form part of the "Sales" route, but each forms a different portion of the timeline. This feature facilitates further segmentation of the process, which in turn facilitates an automation of error reporting and associated improvement of the various functions within the process.
• Fig. 4 depicts an exemplary workflow, such as a workflow illustrated in Figs. 3A and 3B, according to an embodiment.
• a workflow including both type 1 action and type 2 action is shown in Fig. 4 for the purpose of illustration only. It should be noted that it is not essential, according to the present approach, for a (low-level) workflow to include both a type 1 (constrained) action and a type 2 (unconstrained) action; in many cases only one of the two is required.
• the exemplary workflow is identified by a human-intelligible label 400, and an actor (e.g. "Sales", quality assurance “QA”, “Manufacturing”, “Additional Dept", “Paintshop”, “Administrator”, or any other predetermined personnel, machinery, software function, etc.) who performs the action(s) of the workflow is identified by a human-intelligible label 401.
• the workflow begins with a type 1 action step 410, the performance of which leads to one or a plurality of outputs 411, 412, 413, 414, for example based on satisfying one of a plurality of conditions (e.g. different sizes, categories, etc.) or based on a decision (e.g. approved or rejected).
• One or more of the plurality of outputs may lead to a corresponding type 2 (unconstrained) action step, while one or more of the plurality of outputs (e.g. output 414) may lead to a corresponding next-step label that identifies the next sequence to which the workflow proceeds (e.g. Sequence 8).
• a corresponding next-step label that identifies the next sequence to which the workflow proceeds.
• Sequence 8 There may be occasions when the performance of action step 410 fails to produce an output, for example when none of the conditions are met, in which case the action step 410 returns a failure 415, and the workflow is diverted to an exception path (explained below).
• a type 2 (unconstrained) action step differs from a type l(constrained) action step in that a type 2 action step can comprise a series of actions or running a sub-routine of programming that is outside of the workflow document (the sub-routine can be written, or example, in C Sharp, or another conventional linear programming language).
• a type 2 (unconstrained) action step may be automated location and retrieval of a component part, automated assembly of a component part to an object, or generation of a certificate of quality.
• Each of the type 2 action steps 420, 430, 440 leads of one of a plurality of outputs 421, 422, 423, 434, 435, 436, 447 (e.g. component part A, component part B, component part C, etc.).
• Each output 421, 422, 423, 434, 435, 436, 447 then leads to a corresponding next step identified by a human- intelligible next-step label, which identifies a path- Pathl, Path 2, Path 3, Path 4, Path 5, Path 6, Path 7 , Path 8 - to be followed from the present workflow.
• Path 1, Path 2, Path 3, Path 4, Path 5, Path 6, Path 7 , Path 8 need not represent different sequences, and some of the next-step labels may be the same in cases where different action steps or different outputs of an action step leads to the same next step, and one or more next-step labels may be completion of the process.
• Fig. 5 illustrates an exemplary implementation of the workflow program document of Figs. 3A and 3B. For ease of reference, some of the columns shown in Figs. 3A and 3B have been removed in Fig. 5.
• the process begins with the label “choosePart” (Ref 1-4) by actor “Sales”.
• this workflow has only type 2 (unconstrained) action and so the workflow proceeds to action step 2 "Part Lookup”. It is determined that the required part is a custom manufactured part and so the performance of action step 2 returns the output "Custom Manufacture” (Ref 3). If the part is successfully located and retrieved, the workflow returns the outcome as "Success” and proceed to the next-step label "sendToSales".
• the workflow program document is then read to proceed to "sendToSales" (Ref. 5-9) by actor "Sales", as shown by route 1.
• This workflow involves first performing a type 1 (constrained) action step of routing, where a decision is made to determine where the part is sent. This may be performed by a human operator, or a software function or Al agent by selecting an option from a plurality of options e.g. stored on a database based on one or more criteria or specified in a document. In the present example, it is determined that the part is to be sent for painting (Ref. 8) and no type 2 (unconstrained) action step is required. The output of action step 1 leads to the corresponding next-step label "sendToPaintshop".
• the workflow program document is again read to proceed to the workflow "sendToPaintshop” (Ref. 19-20), as shown by route 2, performed by actor “Paintshop", which involves a type 2 (unconstrained) action step "Painting". Again, this action step may be performed by a human operator or by robotics controlled by appropriate software. Once the painting of the part completes, the action step 2 returns an outcome of success that leads to the corresponding next-step label "sendForFinalQA" (Ref. 19).
• the workflow program document is again read to proceed to the workflow "sendForFinalQA” (Ref. 21-22), as shown by route 3, performed by actor "QA”, which involves a type 1 (constrained) action step “Approval”. Again, this action step may be performed by a human operator or by sensors coupled to an appropriate control device. If it is determined that the painted part passes quality assurance and is approved (Ref. 21), the workflow proceeds to the corresponding next-step label "sendToShipping".
• the workflow program document is again read to proceed to the workflow "sendToShipping" (Ref. 23), as shown by route 4, which is performed by actor “Sales” and involves a type 2 (unconstrained) action step "Ship Part".
• This action step may be performed by a human operator or by automated robotics. Once the action step 2 is completed, the process is completed.
• a workflow program document may include conditions or filters specifying which objects or tasks individual actions are applicable to, which may include lists and/or wildcards.
• Parameters and attributes of an object or a task that is the subject of the process being automated may be defined in an object or task definition document separate from the workflow program document, for example in a high-level programming language editable only by authorised and/or experienced programmers or supervisors.
• the object (or task) parameters and/or attributes may be manually adjusted for an individual object (or task), and the object (or task) may be reinserted in the workflow at a chosen point.
• a machined object may be diverted from the workflow and sent for correction treatment and have one or more parameters manually adjusted, and then reinserted at an appropriate point in the workflow with modified parameters, for example at a preceding action step that checks the object parameters.
• an additional column may be included in the workflow program document to indicate when an object has been manually treated, or it may be included into the object or task definition document without modifying the workflow program document. In cases where it is determined that a given workflow or action step frequently leads to manual intervention, such "manual intervention" may then be defined as an additional low-level workflow.
• Figs. 6A and 6B show another example of a workflow program document for automation of a document generating and signing process. Similar to Figs. 3A and 3B, Fig. 6A illustrates the left half of the exemplary workflow program document while Fig. 6B illustrates the right half of the exemplary workflow program document.
• the workflow program document Figs. 6A and 6B is read and executed in the same way as the workflow program document of Figs. 3A and 3B, as shown in Fig. 7.
• the process begins with the label "start” (Ref. 1-5), with an action step 2 "Add Document” performed by actor “Sales”.
• the performance of the action step 2 returns an output of "Internal review", which corresponds to the next-step label "sendToSales".
• the actors herein may be a human operator, a software function, an Al agent, etc., such that the action steps may be manually performed or performed by hardware or machinery controlled by appropriate control software.
• the following techniques will be used to set up the next step in the high-level workflow.
• ⁇ This could be an individual or could be assigned to an internal group where any person in the group might complete the step, or could be performed by an artificial intelligence agent.
• o Filter D will take the first row from filter B and look for the Action Step 1 column. This identifies the Simple Step to execute as part of step 1.
• o Filter E will take the first row from filter B and look for the Comms column. This identifies the communication parameters (for example, E01 identifies the information or content which needs to be communicated with the actor who needs to complete the Simple Step, such as instructions related to the action they need to take, or a communication which is sent to them to inform them of a task that needs to be completed, as well as instructions regarding how to complete the task as accurately and completely as possible) to be used by the Action Step 1.
• E01 identifies the information or content which needs to be communicated with the actor who needs to complete the Simple Step, such as instructions related to the action they need to take, or a communication which is sent to them to inform them of a task that needs to be
• Step 1 o Filter E will identify "E01" as the communication parameter to be extracted from the Communication templates
• a Routing Step will be executed using the communication parameters E01, and will have the following options for the Sales user to select from: Send to Commercial, Send to Legal, Send to Other Reviewer, Send for Signature, Void Document (these are the values in the Action Step 1 Output column which match the rows identified by filter B).
• the Complex Step has the title of "Signatures” and when this sub-routine is executed, the following actions are automatically carried out under the control of the software (sub-routine), for example, the actor is asked to confirm the recipient details for the enitity (e.g, customer ) who needs to sign the document, and then the sub-routine automates the entire signature process, ensuring that completed signatures are received from all relevant parties, and also deals with exceptions, where if a party declines to sign, the sub-routine handles this, and returns to the actor to ask what needs to happen to handle the exception (for example, does Legal need to modify, etc).
• the software sub-routine
• o Filter E is designed to run after the subroutine completes and is designed to identify the rows where the Outcome of the Complex Step/Subroutine is matched (for example, a Failure outcome results). A Failure outcome indicates that the document was not signed as a result of the "Signatures" sub-routine execution.
• o Filter F is designed to be run after the Complex Step/Sub-routine completes and starts with the results from Filter E and is designed to check the Action Step 2 Output from the Complex Step/Subroutine (e.g.. Requires Legal Advice)
• the outcome of the sub-routine is Failure due to signatures not received.
• the subroutine provides the outcome of Failure but it also provides further information that the Failure outcome requires legal advice, another option is that the Failure outcome requires an update, as shown in Fig 6B. It is also possible to have a Failure without a specific output if the sub-routine does not return a specified output.
• the "Signatures" subroutine will execute based on the filters above. During the subroutine there will be a step assigned to the Sales user to send the contract for Signatures. There are two possibilities here: 1. The Sales user realizes that they need Legal output before they send for signatures and decide not to send but first mark the contract as needing legal assistance (it could also be the case that the subroutine execution results in the contract being marked as needing legal assistance without the need for the sales person to make that decision). 2. The Sales user sends for Signatures, the client decides not to sign and sends back a comment, the sales user then realizes based on the comment that they need legal assistance and mark the contract as needing legal assistance.
• the Next-Step Label is then determined based on the Outcome and Output from the subroutine (this will be "sendToLegal")
• the filters and filtering operations described above are preferably carried out by the operation of software programming code, developed in a linear programming language, such as C Sharp. Such programming code sits outside of the workflow program document.
• Fig. 8 illustrates an example based on Figs. 3A and 3B in which execution of the workflow program document encounters an unexpected or undesirable outcome.
• the process begins with the label "choosePart”.
• the actor “Sales” performs the action step 2 "Part Lookup”, which returns the output "Custom Manufacture” (Ref. 3) with the corresponding next-step label “sendToSales”.
• the workflow program document is read and the workflow proceeds to the label "sendToSales", as shown by route 1.
• the actor "Sales” performs the action step 1 "Routing” and determines the output "Send to QA" (Ref. 6) which corresponds to the next-step label "sendToQA".
• the workflow program document is again read and the workflow proceeds to the label "sendToQA", as shown by route 2.
• the actor "QA” performs the action step 1 "Approval” and outputs "Approved”.
• the action step 1 output leads to the action step 2 "Create Certificate", which fails to complete (Ref. 11) and leads to the corresponding next-step label "exception”.
• the workflow program document is again read and the workflow is diverted to the exception path (Ref. 24) for exception handling, as shown by route 3.
• the actor "Administrator” is called to perform one or more rescue or remedial actions to resolve the exception.
• the exception path ends with a corresponding re-entry label, which directs the workflow back to a re-entry point in the workflow program document that is the sequence where the exception occurred.
• An exception handler may be implemented in any suitable and desired manner, for example by providing a plurality of selectable options including providing a patch for the workflow program document and/or providing an option to bypass a problematic workflow.
• a non-limiting exemplary exception handling interface is shown in Fig. 9, in which an exception handler form is presented.
• the interface comprises elements that allows an administrator to input data and/or instructions (e.g. to select an option, to substitute a part of the workflow program document with a correction or update, etc.) and optionally elements that allows output of information to the administrator (e.g. options for exception handling, prompts for input, error messages for invalid inputs, etc.).
• the exception handling interface may be displayed to an exception handler such as a predetermined actor (or group of actors), for example the actor associated with the sequence that leads to the exception, to a designated administrator, and/or to an Al agent trained to handle exceptions.
• the exception handling interface may be displayed in conjunction with the workflow program document, e.g. in the form of a popup window, or it may be sent e.g. as a link or a document to the exception handler or multiple exception handlers via e.g. email, instant messaging, notification, etc.
• the system may generate a report describing the error that caused the exception, to suggest possible causes for the error, to suggest possible solutions for resolving the exception, to provide a link to each suggested solution that directs an operator to a corresponding section of the workflow program document, or to provide an editable patch for modifying the workflow program document.
• End user behaviours can be unpredictable, especially when under time pressure or due to a lack of experience with new systems. Due to time and cost pressures, enterprise systems often do not cater for
• an experienced administrator or trained Al agent may identify the exception and take corrective or remedial actions without interrupting the execution of the process, thereby conserving time and
• the exception handling functionality is preferably implemented by software programming code developed in a linear programming language such as C Sharp.
• the same interface may be used to modify the workflow program document. For example, if during execution, the process encounters an unexpected or undesired condition or outcome that interrupts a particular workflow, the process may be allowed to proceed by re-routing from the workflow program document.
• the generation of a progress report may be automated without involvement from a human operator.
• coding the workflows of a complex process using the uniform framework of the present approach enables automated reporting capable of capturing every path that is taken and in a sequential manner, for example:
• the automatically generated report includes an identifier from the workflow program document that uniquely identifies the path, e.g. "Ref", as well as an identifier (e.g. an email address of an individual) 30 of the actor that performed the action on behalf of a queue or a group.
• the report can enable automated analysis to be performed, e.g. of the productivity of individuals in various roles within an organisation or the performance of machinery or software. Such a report can be easily and straightforwardly interpreted by human supervisors or software supervisory functions.
• a common low-level workflow or series of low-level workflows for a complex process is an extended or complex approval process involving multiple actors and often with multiple dependencies.
• An example of such a complex approval process is illustrated as a flow diagram in Fig. 10.
• FIG. 11 An exemplary workflow program document for a complex approval process is shown in Fig. 11, which encode the approval process of Fig. 10.
• the exemplary workflow program document is defined using a variant of the tabular framework described above in relation to Figs. 3A, 3B, 6A and 6B.
• the present approval process workflow program document is evaluated after each event, for example after each approval or rejection.
• the column “Approval” gives a label that uniquely identifies an approval category.
• the column “Approver” identifies the individual, group, queue, software function, etc. that is responsible for the corresponding approval step.
• the column “Approval Dependencies” identifies one or more "Approval” that must be confirmed to satisfy the dependency condition of the corresponding approval step before this approval step can complete.
• the column “Conditional” identifies additional conditions that must be met before the corresponding approval step can complete.
• the column “Terminal” identifies an approval step the rejection of which is terminal.
• the entire approval sequence is aborted, and the workflow is returned to the originator who initiated the approval process if the corresponding approver rejects the approval step. If the "Terminal" column is marked as FALSE for a particular approval step, the approval sequence may continue regardless of the outcome of the approval step.
• the column "Human Selectable” identifies an approval step that, when marked TRUE, allows the originator to determine at runtime if the approval step is required or not.
• the present workflow program document can be run as a sub-routine called by a type 2 (unconstrained) action step in the workflow program document of Figs. 3A, 3B, 6A and 6B, or as a separate workflow program document to be run in parallel, prior or subsequent to the workflow program document of Figs. 3A, 3B, 6A and 6B.
• a method of developing and using a new tool for the automation of a complex workflow includes the development and use of the workflow program document 121 described above, and also the development and use of the linear programming code 122 mentioned above, outside of the workflow program document, for implementing the filtering steps on the rows and columns of the workflow program document.
• the development and use of the new tool also includes the selection and reuse/use of an existing visual representation programming tool or framework 123, such as the DocuSign CLM tool, such that only the basic framework of such existing tool is used (the basic wireframe structure, as it exists, "out of the box"), such that basic functions of such existing tool (such as a routing function) can be called upon by the new tool without having to develop the software code for such existing basic functions (such as routing).
• an existing visual representation programming tool or framework 123 such as the DocuSign CLM tool, such that only the basic framework of such existing tool is used (the basic wireframe structure, as it exists, "out of the box"), such that basic functions of such existing tool (such as a routing function) can be called upon by the new tool without having to develop the software code for such existing basic functions (such as routing).
• a method of developing the new tool is shown in Fig. 13, and has a first step 131 of developing the workflow program document 121, a second step 132 of developing the filtering code 122 using a linear programming language, such as C Sharp, and a third step 133 of selecting an existing visual programming framework 123.
• a method of using the new tool is shown in Fig. 4, and has a first step 141 of using the workflow program document 121, a second step 142 of using the filtering code 122, and a third step 143 of using the existing visual programming framework 123, in the manner as herein described.
• the use of the existing visual representation tool involves not changing the existing visual representation tool at all, it is used by the new tool in the same state of the existing tool regardless of the specific workflow that is being implemented by the new tool. It is used for its existing basic functionality, as a basic skeleton, or wireframe framework.
• the bespoke modifications to create a new specific workflow are carried out by the new workflow program document taken in combination with the linear programming code as well as the existing basic functionality of the existing visual representation language tool.
• the routing action is listed in the appropriate table of the workflow program document, it is then filtered using the filtering functionality of the linear programming code (e.g., written in C Sharp), and the linear programming code makes a call to the existing routing function included in the native out of the box basic functionality of the existing visual representation programming language tool.
• the routing functionality is no need for the routing functionality to be re-coded in the linear programming language, as such basic functions are already coded in the existing visual representation programming language tool.
• MLAs Machine Learning Algorithms
• MLAs Machine Learning Algorithms
• Supervised learning MLA process is based on a target - outcome variable (or dependent variable), which is to be predicted from a given set of predictors (independent variables). Using these set of variables, the MLA (during training) generates a function that maps inputs to desired outputs. The training process continues until the MLA achieves a desired level of accuracy on the validation data. Examples of supervised learning-based MLAs include: Regression, Decision Tree, Random Forest, Logistic Regression, etc.
• Unsupervised learning MLA does not involve predicting a target or outcome variable per se. Such MLAs are used for clustering a population of values into different groups, which is widely used for segmenting customers into different groups for specific intervention. Examples of unsupervised learning MLAs include: Apriori algorithm, K-means.
• Reinforcement learning MLA is trained to make specific decisions. During training, the MLA is exposed to a training environment where it trains itself continually using trial and error. The MLA learns from past experience and attempts to capture the best possible knowledge to make accurate decisions.
• An example of reinforcement learning MLA is a Markov Decision Process.
• MLAs having different structures or topologies may be used for various tasks.
• MLAs includes artificial neural networks (ANN), also known as neural networks (NN). Neural Networks (NN)
• a given NN consists of an interconnected group of artificial "neurons", which process information using a connectionist approach to computation.
• NNs are used to model complex relationships between inputs and outputs (without actually knowing the relationships) or to find patterns in data.
• NNs are first conditioned in a training phase in which they are provided with a known set of "inputs” and information for adapting the NN to generate appropriate outputs (for a given situation that is being attempted to be modelled).
• the given NN adapts to the situation being learned and changes its structure such that the given NN will be able to provide reasonable predicted outputs for given inputs in a new situation (based on what was learned).
• the given NN aims to provide an "intuitive" answer based on a "feeling" for a situation.
• the given NN is thus regarded as a trained "black box", which can be used to determine a reasonable answer to a given set of inputs in a situation when what happens in the "box" is unimportant.
• NNs are commonly used in many such situations where it is only important to know an output based on a given input, but exactly how that output is derived is of lesser importance or is unimportant.
• NNs are commonly used to optimize the distribution of web-traffic between servers and in data processing, including filtering, clustering, signal separation, compression, vector generation and the like.
• the NN can be implemented as a deep neural network. It should be understood that NNs can be classified into various classes of NNs and one of these classes comprises recurrent neural networks (RNNs).
• RNNs recurrent neural networks
• RNNs Recurrent Neural Networks
• RNNs are adapted to use their "internal states" (stored memory) to process sequences of inputs. This makes RNNs well-suited for tasks such as unsegmented handwriting recognition and speech recognition, for example. These internal states of the RNNs can be controlled and are referred to as “gated” states or “gated” memories.
• RNNs themselves can also be classified into various sub-classes of RNNs.
• RNNs comprise Long Short-Term Memory (LSTM) networks, Gated Recurrent Units (GRUs), Bidirectional RNNs (BRNNs), and the like.
• LSTM Long Short-Term Memory
• GRU Gated Recurrent Unit
• BRNNs Bidirectional RNNs
• LSTM networks are deep learning systems that can learn tasks that require, in a sense, "memories” of events that happened during very short and discrete time steps earlier. Topologies of LSTM networks can vary based on specific tasks that they "learn” to perform. For example, LSTM networks may learn to perform tasks where relatively long delays occur between events or where events occur together at low and at high frequencies. RNNs having particular gated mechanisms are referred to as GRUs. Unlike LSTM networks, GRUs lack “output gates” and, therefore, have fewer parameters than LSTM networks. BRNNs may have "hidden layers" of neurons that are connected in opposite directions which may allow using information from past as well as future states.
• Residual Neural Network (ResNet)
• Deep networks naturally integrate low/mid/high-level features and classifiers in an end-to-end multilayer fashion, and the "levels" of features can be enriched by the number of stacked layers (depth).
• the implementation of at least a portion of the one or more MLAs in the context of the present technology can be broadly categorized into two phases - a training phase and an in-use phase.
• the given MLA is trained in the training phase using one or more appropriate training data sets.
• the given MLA learned what data to expect as inputs and what data to provide as outputs, the given MLA is run using in-use data in the in-use phase.
• MLA's can advantageously be applied to the automation of complex processes, to identify patterns in such processes which already exist, and to use such identified patterns to help better automate processes going forwards.
• the workflow data in a series of workflow program documents can be recorded, for example, in a log document, while the workflow program documents are being processed by the software components, and the log document is then analyzed by an MLA.
• a log document is used to track the execution history of every workflow instance, and is created at the start of the workflow instance. At the end of the processing of every path, a new log line is appended to the end of the log document to record the results of having processed that path.
• a typical line in the logfile will contain:
• 'Actor' refers to the unique individual that completed the step, for example if it was assigned to a queue, which unique individual took action on behalf of the queue. If the task is assigned to a variable and a group of actors, 'Actor' will return the unique individual who took action.
• the log document allows the administrator to uniquely identify the historic steps that were taken, by whom and when, allowing an MLA to interpret the history and identify patterns.
• the log document also allows the administrator to more easily debug an exception situation allowing the administrator to understand how the exception was reached.
• the MLA may identify repeated or similar sequences. Based on this, the MLA may suggest edits to a workflow program document. For example, as a process is being automated, the MLA may suggest steps to encode a component which is executed similarly to another component, or may suggest steps for use in a component of another process. Alternatively, small differences in similar sequences may be identified, for example, highlighted, to assist a user in determining if differences were intentional or if the processes might usefully be made more consistent. Possible errors may be identified, for example, if one portion of a workflow program document usually contains a particular step and it is omitted in one instance this may be flagged. Templates may be suggested from frequently used blocks.
• the MLA can operate on workflow documents for a single process or may operate over multiple document instances for similar or dissimilar processes.
• the suggestions may be invoked when creating or amending documents or separately when reviewing documents. Suggestions may be provided during run time in the event of an exception.
• the invention provides a computer implemented method for identifying patterns in the automation of one or more processes, having steps of: d) recording (step 151) workflow steps in a log document, the log document including data describing an execution history of processing of at least one workflow program document, where the workflow program document comprises rows and columns, where each row represents one of a plurality of paths through a portion of a process to an outcome of the portion of the process, and where each column represents a human readable label used to describe a component of the process ; e) processing (step 152) the log document with a machine learning algorithm to identify at least one pattern suggesting an edit to a workflow program document to be modified; f) based on the identified pattern, suggesting (step 153) an edit to the workflow program document, wherein the edit comprises at least one of: a) a sequence of steps to perform a further component of an existing process to be automated; b) a sequence of steps to perform a component of a further process to be automated; c) an identification of
• the step of suggesting an edit provides to a user one or more suggested modifications to the workflow program document for the process, based on the exception.
• the machine learning algorithm receives input runtime data regarding the occurrence of at least one exception, and provides information suggesting an edit to a corresponding workflow program document for the process, based on such runtime data.
• the machine learning algorithm receives input runtime data concerning execution times and provides information suggesting an edit to a corresponding workflow program document for a process, based on such runtime data.

Landscapes

• Business, Economics & Management (AREA)
• Human Resources & Organizations (AREA)
• Engineering & Computer Science (AREA)
• Strategic Management (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Operations Research (AREA)
• Game Theory and Decision Science (AREA)
• Development Economics (AREA)
• Marketing (AREA)
• Educational Administration (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (12)

Publications (1)

Family

ID=88840704

Family Applications (1)

Country Status (1)

• 2022
  • 2022-01-27 EP EP22706086.0A patent/EP4295289A1/de active Pending

Similar Documents

Legal Events