Workflow Sample

About account payable, a lot of complicated requests will be heard.

Want to know about payment before the bill comes in.
Want to divide production cost from general cost.

Those requests will be heard sooner or later.

Today's workflow is a spin-off of yesterday's "Improving Your Accounts Payable Process in Steps."

<Tasks>
0. Prediction, 1. Receive Invoice, 2. Approve Payment, 3. Inquiries, 4. Payment

[Accounts Payable Management - Predictive Management: "2. Approve Payment" screen]

To continuously improve business processes is to polish corporate competitiveness. In particular, the financial, information communication and distribution industries are already beginning to have established BPM practices. More vendors who offer BPM systems have a variety of workflow templates.

The primary areas for BPM application include complaint management, loan approvals, management of accounts payable in resource management and procurement, reimbursement management and asset management. Corporations with a long history of BPM activities tend to apply BPM to difficult business processes, such as management of accounts payable and budget planning.

The below workflow is a very simple form of accounts payable management. There is no Swimlane representing the accounting department, but if they refer to the list of approved invoices, they can pay them at once at the end of the month.

<Tasks>
1. Receive Invoice, 2. Approve Payment, 3. Inquiries

[Management_Supervisor : "2. Approve Payment" screen]

title <<Payee and use (ex: Japan Printing/50000 leaflets)>>
Payment to (string)
Amount (numeric)
Ordered on (date)
Payment deadline (date)
Summary of invoice (string: text box 3 lines)
Scanned invoice (file)

<<Control>>

Supervisor approval (select:OK/No)
Correspondence (discussion)

Of course, it would not be bad to define the role of accounting. That way, the upstream purchasing employee can see whether the downstream accounting made the payment or not. Of course, the deadline of [4. Make Payment] corresponds to the process data item "payment deadline."

<Tasks>
1. Receive Invoice, 2. Approve Payment, 3. Inquiries, 4. Make Payment

Japan is facing a serious power shortage. Authorities are saying that at the summer peak, only 80% will be supplied to the Tokyo area. In addition to using stored electricity and withholding air conditioning, the country will have to take drastic measures such as "reducing human transportation" and "suspending plant operations." This month, more companies will be eagerly considering telecommuting systems for the imminent summer months (July–).

Of course, it's almost impossible to design a perfect telecommuting system. We recommend applying the concept of the BPM cycle to application flows and reporting flows, which means endeavoring to "gradually bring them closer to the ideal flow."The important point is real-time visualization of telecommuting progress. (BPM: Business Process Management)

In the below workflow definition, the user can easily record whether he/she decided to cancel telecommuting, in Smooth Reporting by Telecommuters. This enables accurate recording to changed and canceled schedules.

Reference: Of course! Approving Request of Telecommuting Should Be Through Cloud Computing

<Tasks>
1. Report Work, 1b. Report Work, 2.Confirm, 3. Inquiries

[Telecommuting-Report/Cancel: "2.Confirm" screen]

title (string) <<Ex: May 16 Ichiro Sato (name will be added automatically)>>

<<Telecommuting info>>

Telecommuting employee (user)
Telecommuting on [deadline of task 1] (date)
Supervisor (user)
Intend to: (select: telecommute as scheduled / cancel telecommuting)

<<Control>>

Inquiries? (select: Yes / No inquiries)
Correspondence (discussion)

By the way, managing processes with the "Intend to (telecommute as scheduled / cancel telecommuting)" will let managers monitor real-time performance, i.e., "number of telecommuters in the previous week" or "total number of days telecommuted." On the assumption that this information does not have to be hidden, you may want to consider giving all employees process data viewer authorization.

If the supervisor is the primary one in charge of the telecommuting system, you can add a task specifically for confirming cancellations, to acquire more explicit data on canceled schedules (below).

<Tasks>
1. Report Work, 1b. Report Work, 2.Confirm, 2b. Confirm Cancellation, 3. Inquiries

Instead of having telecommuters access the company's server and create an "opening" in the firewall all the time, it's better to keep a certain amount of data "on the Cloud" to reduce repeated access. Remember, when you prioritize everything as "important data," you may not be able to protect the truly pivotal stuff. (Ancient Japanese castles during the Sengoku period had inner and outer moats, and apparently castles with "wide inner moats" cost a lot more for security!)

Today's workflow is a spin-off of yesterday's "Of course! Approving Request Of Telecommuting Should Be Through Cloud Computing." The workflow is for registering work schedules in batch—because work schedules are something you can keep within the outer moat.

By the way, it's convenient to be able to register your work schedule in batch, but unlike individual workflows it may be harder to report completed work within a sequence. (Or so it seems.) In this case, you can just separate the "registering workflow" and "reporting workflow" in a [1:n] relation.

<Tasks>
1. Request, 2. Approval, 3. Action against Send Back

[Telecommuting <Register Schedule in Batch>:
Message Throwing Intermediate Event (HTTP) Setting]

It is right to say "Keep important Data inside server."
But it's also right to say "Keep them upon cloud computing."
If you have excellent engineers in your company, there might a way to trust only in your own inside server.
But still it sounds nonsense to say "Never use servers except one inside."
It sounds like "Every electric power must from private electric generators" or "Every money must kept inside safe, not in the Bank."

Now, what kind of affairs should be in cloud computing?
We'll show you an example of "Approving Telecommuting Requests" on cloud computing.
We are going to expand from this basic model.
Similar;"A Workflow for a Telecommuting System"(Mar.23.2011)

<Tasks>
1. Request, 2. Approval, 3. Report

[Telecommuting-Request: "2. Approval" screen]

Business process kaizen requires editing best practices, including that of simple work. If an employee in charge of checking data entry work encounters a performance that he finds excellent, it's good to acknowledge this in the corporate portal.
In the below workflow, the leader decides which case to add as a "best practice," from the cases selected by checkers.

<Tasks>
1. Register Image Data, 2. Accept & Schedule, 3. Text Data, 4. Check, 4b. Best Practice Selection, 5. Record in Work Log, 6. Answer Questions

[Efficiently-Digitizing < Best Practice >: "4b. Best Practice Selection" screen]

The data entry service workflow we previously proposed is designed to be operated by a company who prepares image data and sends to a contract worker. Once you have a contract-based teleworking workflow, you 'll also want a workflow for paying fees according to performance.

The below workflow adds a billing flow by the accounting department.

<Tasks>
1. Register Image Data, 2. Accept & Schedule, 3. Text Data, 4. Check, 5. Record in Work Log