Workflow Sample: January 2014

For Outsourcing Software companies or Business Process Outsourcing companies, the "Delivery Date" that promised to the customer is absolutely unmistakable. Once they delayed, their credibility would fall to the ground. However, you can't be sure that the "delivery date" is shared to be recognized thoroughly.

Team members would rather continue to recognize the deadline for the "processing of their own". In other words, they barely have chances to recognize the "Delivery Date" that is the deadline of entire steps. Watching the screens of the Workflow system, even though the deadline of 'underwritten processing of their own' is obvious, the "Delivery Date" which should be important for the team is hardly to be recognized.

Furthermore, "cross-project information" such as 'a lot of Delivery Dates are concentrated in this month', there will be no chance to grasp them.

In the following Workflow, "Data of Delivery Date" is arranged to be synchronized to a [Calendar system]. Specifically, "Delivery Date data" in the 'order information' will be automatically written to the Google Calendar, using the secure communication of OAuth. Looking at the calendar, "distribution of Delivery dates" is obvious at anytime. This information will be a very important source not only for the team members, but also for directors and auditors.

[Contract-Delivery flow]

It is better to handle the "Attendance and leaving information" on Workflow for an Organization that handles various daily works in the Workflow (Paperless/ Digitize).

Anyhow, you manage it on Workflow, how about making attendance time and leaving time reported daily, instead of 'creating attendance record once a month'?

It seems nonsense that letting the workers create attendance records while remembering previous month. It will not work as a checking function for the supervisors, even if they handed 'attendance record data of one month' at a time. But suppose if it is a daily check on working hours confirmation, they could give approval during a little time of transportation.

[Timecard]

There are a lot of 'documents to be referred by many people' in a company.
It would be a wide variety of types of documents such as, 'User's Manual' of products, 'Work Manual' of work site, 'Template of Agreement', or 'Company Regulations'. And it would be a big affliction to continue maintenance upon them. Moreover, it would be extremely difficult to control if the documents were required 'to be translated into other languages' at time of revision.

The following Process Diagram shows the work procedure of revising 'Product Manual'. By bringing this Business Process Definition into the system, the locations of revisions and person who finally checked will be recorded automatically.

[Manual Revising]

* Series; Can be used immediately, part 3.

Considering the introduction of the workflow system... I want to evaluate Workflow products by running data that is even a little significative.

In the third of the series, I would like to pick up "General-purpose Work Request" as the theme. The following "General-purpose Work Request flow" is a little bit unusual. Anyway, it can be used for any business. Weirdly to say, it is defined a "business flow that is undefined".

However, it is very important to visualize (to uncover) this "work in the undefined area". The contents which have been asked many times in the "General-purpose Work Request" might mean that some important business processes have not been defined. Suppose if it would become exactly the same flow diagram (*structure), it might be better to operate in another Workflow (Process Model) to automatically record the business history.
*Request structure of "1. Work request" > "2. Completion report" > the "3. Completion confirmation", between two parties

[Work Request flow]