Workflow Sample: Episode 575: Business Improvement in SaaS Vendor Operation (Part 2)

Business: Design Production

A design team where "requests" from in-house come in one after another.

By improving the "Request form" (Starting step) of design creation, it has become possible to handle requests more stably than before. (Reference: "Episode 574: Business Improvement in SaaS Vendor Operation (Part 1)")

As we also prepared an automatic start event (Message Start Event), cases where the Process of "Designing request" is used as "sub-process" have increased as well. In other words, cooperation between business processes has been automated with API POST communication, by placing "call event" and "standby event" in the Business Process diagram (main process) of Sales department or Manufacturing department. (In short, the Process is started with data such as "title of requested item" or "details of requested work", and data such as "design report text" and "deliverable file" is returned at the same time when the work is completed.)

Furthermore, as we also opened to in-house the sample of the main Process to call out the "sub-process", designing work in various departments are to be integrated into the Process of "Designing request" in the future.

Challenge: Skills do not Improved

"Number of Issues been in charge" and "total amount" have been visualized for each designer. In addition, since veteran designers now control on work progress of "designers" as "receptionist", young designers will not commit "no-check delivery" (delivered without checked by anyone).

However, intrinsic? measure of value in designing is "quality".

With this Business Process as it is, I feel worry that the degree of satisfaction for designs in-house will be going down.

Is it impossible to become a Business Process capable of improving skills of the team as a whole a little more? Since we are improving its independency as a "Design request handling process", we would like to think about a mechanism that leads to skill improvement, not just a Business Process for simply to handle numbers of work.

Example of Business Process to call out [Designing request]

[Designing request-Reviewing]

Solution: Review of Questionnaire Format

"Good or bad in a design" cannot be quantified. Even if the designers in the team discuss on a certain design, they will get only mixed opinions. If negative comments are made about the parts that the creator him/herself is satisfied, it can fall into a barren argument. Only if it is a comment about "the part that the creator him/herself is uncertain", it will be acceptable even a negative opinion.

In this business process, a designer describes his/her feeling of reluctance or apprehension about the design, such as for example, "it could be bit brighter", into "3. Preview" to ask opinions to colleagues. (It would be much better to ask "Review, please" verbally.)

Colleague who is asked will select from

I agree
Somewhat agree
I don't think so
I disagree
I don't know

Discussion: Skill Improvement Environment

Designers in Marketing department, in Product development department, in Sales department.

I cannot tell which is better whether "a case where the designer is assigned to each department" or "a case where the design team is independent". Each will have both advantages and disadvantages.

However, as a way to proceed a job, it is never desirable for a situation where workers cannot talk to anyone / cannot consult anyone. Particularly about outputs of designing, it is something that will lead to some conversations even just clicking on "Like" on in-house social network (enterprise SNS).

Especially if you aim "skill improvement as an organization", it can be said that you should continue to explore such a Business Process environment that allows people with the same skills mutually encourage improving.

[Designing Request-Reviewing:"1. Request designing]

<Example of automatic transmission setting in Main process to Sub-process>

key=${sub-process api key}
title=${Title of requested item}
data[1].email=${Requester} #User type
data[6].selects=${Work type} #Select type：Icons/Illustration/…
data[7].selects=${Budget} #Select type：0-5,000/5,000-10,000/10,000-50,000/…
data[8].input=${Desired due date} #Date type
data[9].input=${File format} <span style='color:#0000FF;'>#String type</span>
data[10].input=${Purpose of request} #String type multiple lines
data[11].input=${Details of requirement} #String type multiple lines
data[12].upload: ${Related files} #File type
data[2].input=${URL of Catching Event} #String type
data[3].input=$processInstanceId
data[4].input=${Catching Event Key} #String type

* In order to automatically receive Design report, "URL of Catching Event in connection source Process", "Issue ID of connection source Process", and "Catching Event Key in connecting Process" are mandatory. Other data items are delivered to the extent necessary.

<Data automatically transmitted in Sub-process to Main process>

key=${(Catching Event Key in source Process)} #main-process api key
processInstanceId=${(Issue ID of connection source Process)}
q_designreport=${(Design report)} #String type multiple lines
q_designfiles: ${Deliverable file（to be returned to the connection source Process）} #File type

* String type data item multiple line (field name: q_designreport) that stores "Design report", and File type data item (field name: q_designfiles) that stores "Deliverable file" are needed in the Main process side.

* For data transmission to the Main process, it is on the premise to use a custom format (field name, e.g. q_designreport) rather than the default parameter format (e.g. data [9]. Input).

[Free download]