"Free Trial Account" Issuance Automated And Unmanned

Issuing "Free Trial Account" in practice, manpower required on some occasion by all means. But what men do is only inputting same fixed commands into computer. "Free Trial Account" is sure to be issued by Automated And Unmanned when receiving Applicant information.

In the Workflow model below, It issues "Free Trial Account" without manpower by receiving info from BPM. Only whenever error occurs, human needed. Making inter-working between human and computer is the real pleasure of BPMS.

• Similar:"Automate From Acceptance To Issue On Trial Account"

<Tasks>
1. Application Info, 2. Manual Issue Account

[Trial Account Issue-Automatic Issue: [2. Manual Issue Account]　screen]

Automate From Acceptance To Issue On Trial Account

In any business, "Free Trial" is important. Sending out samples, issuing trial accounts... But don't want to spend much cost on them. We want make [Accepting Free Trial Flow] automated.
Today's Workflow model below is a example of process in issuance of Free Trial account.

<Tasks>
1. Application Info, 2. Issue Account

[Trial Account Issue: [2. Issue Account]　screen]

Ad Hok Flow Without Procedure

"Ad hoc", a Latinic phrase. There is no specific word or phrase for us Japanese, so we use that as it is.
Then what does it mean? For example, we use them like "ad hoc Network" or "ad hoc working area" and it stands for "not permanent" and/or "temporary measure."

In the category of Workflow (Business Process), there're expressions like "ad hoc Task" or "ad hoc workflow." To say in plain words, they are series of tasks that not fixed who or how to proceed. "Circulation of document" and "Multiple approval" cases are introduced as example. How they should be treated, with [Workflow system]? or with [Group ware]? are discussed.

Theme of eighth installment in the BPMN lecture series is "Designing ad hoc Tasks"

-BPMN lecture series Before-

• Split Conditions are a Basic Concept in BPMN
• BPMN Splits for flexible flow conditions
• Automatically Sending Template Emails in the Middle of a Workflow
• How to Design Primary Workflows With Many Baby Workflows
• Eternal Looping
• Never Use Your Own Rules When Designing Workflow Diagrams (interrupting flows that include concurrent processing)
• Same Results, Different Starts (Multiple Triggers)

<Tasks>
1. Task, 2. Task

[BPMN Sample-Ad Hoc <Loop>: "2. Task" screen]

Make Complaint Treatment Efficient With Sharring "Best Practice"

The key to smooth complaints treating is to share the know-how. In other words, how we manage "Best Practice".

It's alright to select the Best out of whole thing weekly or monthly. But we often apt to leave to chance putting it later for what you have right in front of you. You'd better put "Best Practice Point" sequentially through treating complaint.

Similar:

• "Shift Your Tension By "Type Of Complaint""
• "Distinction On Complaints by Priority With Automated Filter"

<Tasks>
1. Register Complaint, 2. Primary Respondent, 3. Correspondence, 4. Report, 5. Best Practice Point
2b. [Urgent] Primary Respondent, 3b. [Urgent] Correspondence

[Complaint Treatment-Best Practice: "5. Best Practice Point" screen]

Distinction On Complaints by Priority With Autmated Filter

The way how to treat complaints are different between companies for their scales or what the sell.
Even distributes on a distributes worth stationary, Listed company must treat it carefully. In other hand, for a company which distributes Free-software to the world wide, they must ignore some complaints. But in any case, accumulation of complaint and analysis on them are very important activity for maintaining their competitiveness.

In the Workflow model below, each complaint is filtered automatically and with higher priority can be acknowledged easier in sight.

Similar: "Shift Your Tension By "Type Of Complaint""


<Tasks>
1. Register Complaint, 2. Primary Respondent, 3. Correspondence, 4. Report
2b. [Urgent] Primary Respondent, 3b. [Urgent] Correspondence

[Complaint Treatment-Sort by Priority: "2b. [Urgent] Primary Respondent" screen]

Shift Your Tension By "Type OF Complaint"

"Complaints" should be treated in different ways up to such a case as the quality of merchandise or service was not good than company would provide, or as even the quality was good but the customer wasn't satisfied.

• A. Deficient (merchandise or service was less than expected quality.)
• B. Disappointment (Quality was enough but the customer expected more.)
• C. Other (Complaint on others except merchandise or service)
• D. Harassment

And about "a person who complains", we can classify into, for example,

• 1. Low risk of losing Regular
• 2. High risk of losing Regular
• 3. High chance of getting Regular
• 4. Low chance of getting Regular

Well now...A-1, B-3, C-2, which Complaint should be treated right away...?

<Tasks>
1.Register Complaint, 2. Primary Respondent, 3.Correspondence, 4. Report

[Complaint Treatment-Individual : "2. Primary Respondent" screen]

Automatic Analysis On Sensor Information And Change The Flow

"Auto-sensing Data comes in!" Should we start Inspection right away? (maintenance on Server, vending machine, internal computers...)
It's not a simple story. Maintenance costs rise up if all the detection of sensors had inspected right at the time. It may affect Corporate cost structure. But you cant leave it.
So make "Conditions" if response immediately or not. In this kind of workflow, the most improving point may be to brush up imposing conditions.
similar article;

• "Maintenance Duty Certainly Is A Flow"
• "Periodic Or Emergency, Maintenance Duty Goes On Almost the Same Flow"

<Tasks>
1. Inspection Point, 2. Inspection Date, 3. Operation of Inspection Report, 4. Repair Date, 5. Operation of Repair Report, 6.Confirmation

[Maintenance Duty-Receive Inspection Data:[2. Inspection Date] screen]

Periodic Or Emergency, Maintenance Duty Goes On Almost the Same Flow

In the article "Maintenance Duty Certainly Is A Flow", we have introduced simple maintenance duty workflow.

But just think about what made you inspect? Of course periodical does, but also External notification such as claims and tip-offs. It's convenient setting up Workflow to start automatically when receiving Inspection Data.

<Tasks>
1. Inspection Point, 2. Inspection Date, 3. Operation of Inspection Report, 4. Repair Date, 5. Operation of Repair Report, 6.Confirmation

[Maintenance Duty-Receive Inspection Data:[2. Inspection Date] screen]

Maintenance Duty Certainly Is A Flow

Maintenance Duties actually is a typical Workflow. It's not all inspection on them. If problems found, they should be repaired to be fixed. And confirmation if the had fixed.
<Tasks>
1. Inspection Point, 2. Inspection Date, 3. Operation of Inspection Report, 4. Repair Date, 5. Operation of Repair Report, 6.Confirmation

[Maintenance Duty-Without Re-examine: "2. Inspection Date" screen]

<Items>

• Title<<Point>>

-Inspection Point-

• inspection Point on GoogleMap(string)
• Ideal Inspection On (date)
• Summary of Inspection(string: text box 3 lines)
• Correspondence (discussion)

-Inspection Report-

• Schedule Inspection On (date)
• Inspected On (date)
• Photo Inspecting (file)
• Inspection Report (string: text box 3 lines)
• Judgment (select:Need to be Repaired/No Need to be Repaired)

-Repair Report-

• Schedule Repair On (date)
• Repaired On (date)
• Photo Repairing (file)
• Repair Report (string: text box 3 lines)

By the way, there are some people who reacts strongly against "Flowchart". When you show business flowchart to one of those flowchart allergy patient, you'd better give those words, "I made a picture of how inspection goes. I'll explain on it fine and easy." It focused on let him say "Ah, it's easy than I expected!"
Now, Workflow below enables office workers who settled Inspection Point, to order re-examine after inspection has Reported.

<Tasks>
1. Inspection Point, 2. Inspection Date, 3. Operation of Inspection Report, 4. Repair Date, 4b. Confirmation on Inspection 5. Operation of Repair Report, 6.Confirmation on Repair

<Items>

• Title<<Point>>

-Inspection Point-

• inspection Point on GoogleMap(string)
• Ideal Inspection On (date)
• Summary of Inspection(string: text box 3 lines)
• Judgment on Re-examine (select:Need Re-examine/No need Re-examine )
• Correspondence (discussion)

-Inspection Report-

• Schedule Inspection On (date)
• Inspected On (date)
• Photo Inspecting (file)
• Inspection Report (string: text box 3 lines)
• Judgment (select:Need to be Repaired/No Need to be Repaired)

-Repair Report-

• Schedule Repair On (date)
• Repaired On (date)
• Photo Repairing (file)
• Repair Report (string: text box 3 lines)

• Maintenance Duty <With Re-examine>
• Maintenance Duty <Without Re-examine>

Same Results, Different Starts

In some cases employees start requesting, in other accountancy start confirming. Yes, business processes in the world are not started from the same occasion. Rather multiple starting occasion (we call "Trigger") should be prepared in most of business processes.

Theme of seventh installment in the BPMN lecture series is "Multiple Triggers."

-BPMN lecture series Before-

• Split Conditions are a Basic Concept in BPMN
• BPMN Splits for flexible flow conditions
• Automatically Sending Template Emails in the Middle of a Workflow
• How to Design Primary Workflows With Many Baby Workflows
• Eternal Looping 
• Never Use Your Own Rules When Designing Workflow Diagrams (interrupting flows that include concurrent processing)

<Tasks>
1a. Task, 1b. Task, 1c. Task, 2. Task

[BPMN Sample <Multiple Start>:"1a. Task" screen]

Clock Register to Launch Application Advances Paid Process automatically Every Month

There's no chance to spy what coworker has claimed for his advance pay if he applied in paper document.
However, those applications had done Online and optimized in company, you often see other person's claim unexpectedly.
And it gradually brings morality and "Commonsense" inside company.

To collect monthly applications in one document per person, [1. Application Advances Paid] task timed to launch on the first day of the month with initialized title like "Mr.Smith March period". A mechanism to make an employee habit of overwrite and save many times over through the month by looping [1. Application Advances Paid] task.

Expanding

• "Bravery To Optimize Money Flow Inside Company"
• "Predicting Expenditure Of Each Month by Registering Bills"

<Tasks>
1. Application Advances Paid, 2. Approval by Supervisor, 3. Response to Notion, 4. Approval by Accounting, 5. Settlement
1b. Input Estimate, 2b. approval by Accounting Manager

[Application Advances Paid-Settlement Confirmation <Auto Launch> :

"1. Application Advances Paid" screen]

Predicting Expenditure Of Each Month by Registering Bills

In the article"Bravery To Optimize Money Flow Inside Company", we didn't mention about "bills".

There must be processes of checking bills form outside before the first Task [1b. Input Estimate].
We would like to build a system that over takes previous process by adding "Message Start Event".

<Tasks>
1. Application Advances Paid, 2. Approval by Supervisor, 3. Response to Notion, 4. Approval by Accounting, 5. Settlement
1b. Input Estimate, 2b. approval by Accounting Manager

[Paid-Settlement Confirmation-Data Connection "5. Settlement" ]

Bravery To Optimize Money Flow Inside Company

Travel expenses, outsourcing costs and labor costs, they all are expenditure. It's good to optimize all company expenditure for a company less than 100 employees. It helps opinions thought the whole company be submitted.
With workflow model below, you can capture every expenditure in your company.

<Tasks>
1. Application Advances Paid, 2. Approval by Supervisor, 3. Response to Notion, 4. Approval by Accounting, 5. Settlement
1b. Input Estimate, 2b. approval by Accounting Manager

[Application Advances Paid - Settlement Confirmation: 5. Settlement]

Some Documents Don't Need the Legal Department's Check

If you have experience with seal/signature/approval processes, you'll know that only a few approvals require the legal department's check. For instance, contracts that only clarify transaction costs, documents to be submitted to authorities, etc., can be sped up by bypassing the legal check.

Let's take the workflows from "Keep At Least the Process of Agreement Drafting Online" and "Should A Contract Be Approved On Printed Paper By Presitent?
and make a new one that can omit the legal check.

<Tasks>
1. Draft Agreement, 2. Check Draft, 3. Revise, 4. Legal Check, 5. Print & Sign, 5b. President's Approval, 6. Record Follow-up

[Signing <Skip legal>: "5b. President's Approval" screen]

Should A Contract Be Approved On Printed Paper By President?

Even a president has his own will!
In Keep At Least the Process of Agreement Drafting Online, There were no appearance of president.
Of course, important agreements require president's approval. If you want to promote 'Optimizing Business process', president himself must join in workflow process.
Who decides it's important? (A big matter.)
Should the document be printed for president? (A small matter)

<Tasks>
1. Draft Agreement, 2. Check Draft, 3. Revise, 4. Legal Check, 5. Print & Sign, 5b. President's Approval, 6. Record Follow-up

[Signing Agreement: "5b. President's Approval" screen]

Keep At Least the Process of Agreement Drafting Online

All agreements, whether between people, companies or countries, are kept on paper. The invention of paper was a truly astronomical event (2,000 years ago in China!). Today in the 21st century, even with the advent of the word "paperless," we still like our agreements to be on paper.

But then, agreements are created on a computer, and the paper versions usually only involve direct signatures. Many corporate presidents sign multiple agreements everyday, often without checking the contents. (Or in Japan and Korea, where the seal is the formal mark, the president's proxy spends the day stamping papers.) Today let's try to visualize the first half of the process, where agreements are created on computer.

<Tasks>
1. Draft Agreement, 2. Check Draft, 3. Revise, 4. Legal Check, 5. Print & Sign

[Signing Agreement: "4. Legal Check" screen]

Never Use Your Own Rules When Designing Workflow Diagrams

Today is the sixth issue of our "BPMN" series. Let's look at "interrupting" events, or items that cancel the operation of other tasks.
There are several ways to interrupt a flow. Let's look at interrupting flows that include concurrent processing. In other words, interrupting other users' work when multiple users are executing tasks simultaneously.

In the below workflow, users A, B and C simultaneously work on separate tasks within the same process. Now, user A can decide to end the entire process arbitrarily. If user A completes task 2a, then tasks 2b and 2c disappear. (This doesn't have an effect when tasks 2b and 2c are already completed.)

<Tasks>
1. Task, 2a. Task, 2b. Task, 2c. Task

[BPMN <Single Terminate>: "2a. Task" screen]

Accounts Payable Management With Later Revison

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

1. Want to know about payment before the bill comes in.
2. 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]

Improving Your Accounts Payable Process in Steps

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]

<Process Data Items>

• 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

• Accounts Payable Management <Supervisor Approval>
• Accounts Payable Management <Payment>

Implement BPM Cycle in Telecommuting Systems!

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]

<Process Data Items>

• 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

• Telecommuting <Report/Cancel>
• Telecommutin <Report/Cancel Confirm>

Smooth Reporting by Telecommuters

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]

Of course! Approving Request Gf Telecommuting Should Be Through Cloud Computing.

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]

Management Is in Charge of Managing Excellent Deliverables

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]

When Telecommuting Is Based on Contracts, You Need a Billing Workflow

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

[Efficiently-Digitizing <<Accounting Checkout >>: "5. Record in Work Log" screen]