The Nimble BPM Blog

While my role on the Eforms Project Team is one of project management and forms design, I realize there are a lot of things going on by the team’s programmers. They are responsible for the accuracy of the workflows, for creating scripts that connect to the campus databases for auto fill-in of information, for creating the automatic emails that get sent to notify approvers that they have a task waiting, and for automatically generating the PDF versions of the form that get distributed once the form process is completed. Our programmers are working very closely with the BP Logix support specialists and developers to resolve problems and apply updates as needed. We all appreciate the assistance and the prompt responses from the BP Logix staff. They go the extra mile to assure that all is working for us.

I returned from vacation yesterday and uploaded the new BP Logix Plug-in for MS Word. This latest plug-in version, along with the recent update of the BP Logix software, makes form design more efficient. I so appreciate the “Upload and Leave Checked Out” feature. In the past, we had to make editing changes to a form in MS Word, save and close it, upload it to BP Logix and finally preview the form to determine if the edit was successful. If it wasn’t, we had to download the form to MS Word and begin the process over. With this software version, we can save the edits in MS Word, leave the form open and use the “Upload and Leave Checked Out” feature to examine the form in the preview mode. Since I have two monitors, I can easily edit the form on one monitor while previewing it on the other. I really like this as it makes editing and correcting a form so much easier. Now, I would like to be able to make the edits, save the form, and simply refresh the preview mode to see updates!

UW-Eau Claire forms conversion project—How much can expected of end-users?

In a university environment, resources are always tight and especially so right now during the recession. While our staff has been doing all the forms design as we learn the BP Logix software, at some point, it will be more efficient for departmental designees to assume responsibility for some of the work. The E-form Project Team discusses this frequently and have recently drafted a proposal on the division of labor.

In summary, it reads like this. A unit responsible for five or more forms or less than 5 forms that require many changes or updates, will be asked to name a unit forms designer. This person would create the form in MS Word using the BP Logix Plug in to add fields such as the input and text boxes, the check boxes, radio buttons, drop down fields, and date field. Once this person had the form elements in the order need, and the styles and formatting completed, he/she would meet with a member of the E-forms Project Team and hand the form off for coding of sections, arrays, system variables, if-then logic, etc. Then, once those items were working properly, the form would be passed along to the E-forms Project Team Programmers who would add the workflow, the knowledge view, the email template, etc.

For units with less than five forms or forms that don’t change very often, we are recommending that those units name a point person who works with the LTS E-forms Project Team as the form is designed. We consider this to be efficient use of everyone’s time.

As one works with new software there are always a few glitches, snags, and irritants. Here are a few of the snags we have come across. We must emphasize that the BP Logix staff have been very helpful in getting us through many of these challenges and in writing special code when we needed it.

Glitches, Snags, and Irritants

One irritant and time consumer is not having a WYSIWYG interface. We create our forms in MS Word using the BP Logix Plug-In and add some of the coding there. Then we save the file and load it to the BP Logix server, make more changes in the forms control area and then preview the form. As errors are caught or the user remembers an addition, there is a lot of going back and forth between the MS Word view and the BP Logix Preview. We have also run into some glitches by using Word tables for our design. We must be very careful not to specify a table, row, column or cell width or height. On the other hand, we can run into formatting issues if we do not specify a length for a form’s input fields. It’s little things like this that we keep learning about as we go along that extend our learning curve.

Our users requested a Save and Close button so that if they are in the middle of completing a form or checking a form and get interrupted, they can save and close the form. They also wanted a Save and Continue button for when they receive a phone call or get asked a quick question. Our initial set up of these buttons worked for everyone along the approval process except for the form initiator—the person who first fills out the form. Our programmer Mike worked with Kris from BP Logix to resolve the problem.

Workflow design and getting the second approval step to repeat so the form could be approved by several people proved a challenge. It took a special script written by the BP Logix programmers to help us over this hurdle.

All of this slows us down as we try to move the project along. Once we have the first few forms ready to go, we hope to have solved most of the puzzles we need to solve.

Being in a university environment has proven to be a bit challenging for us as we use the BP Logix software and for BP Logix as they try to understand the policies and procedures at a university. Together we have both learned a lot, solved a lot of problems and will soon have a number of widely used campus forms error-free!

This week we taught one class a day for the first of the BP Logix end users. During the class we divided the participants into groups of three and assigned them a role of either form initiator, employee, or approver. We then explained the overall process to them so they could become familiar with the BP Logix jargon. Next, they logged into the server and began filling in our Summer Session Appointment form. The “official” initiator in each group forwarded the form to the “employee” who accepted the form and then sent it on to the first “approver.” The groups sat in the same row in the computer lab so they could easily move their chairs to view each other’s screens. We heard comments like “slick,” “oh, nice,” and “I’m so glad it can do that!” We now have approximately half of the 150 users of the old system ready to use forms in BP Logix. We will offer training for the remainder in the near future.

Most of the questions we received proved to be policy and/or procedure questions for handling the forms. Some common exceptions to the normal situations were described so we are able to edit the form to better fit the needs of all. For example, instructional academic staff may be assigned credit load not only for courses but also for advising. While we have agreed to continue to redesign this first form, we are rethinking the whole process of when a form is frozen and when we will take additional changes. That, to me, includes our redesigning our whole process for seeking input on the design of a particular form, especially, those used across the campus. This time we chose a small group of stakeholders and worked with them. While they were very knowledgeable about the form and its use, the feedback received was not inclusive. During our next forms design efforts, we may hold “town hall meetings” in the academic buildings and let the users see a draft that can then be commented on by all in attendance. Perhaps that will help us get at a wider range of scenarios and shorten the time it takes to arrive at a final form.

Next week, I will describe a few of the design and workflow glitches we are experiencing. The Eforms Task Team here at UW-Eau Claire have found the BPLogix staff most receptive to our calls, efficient about delivering solutions, and very open to making modifications to their program based on our suggestions.

As reported in the last blog entry, we have moved to BP Logix’s newest software version. Forms development changed, and we went through the 6 forms we had developed in the old version and replaced the old coding with the new. The new version features a graphical user interface for setting required fields and for “if. . .then” scenarios. It’s very easy to set up and saves time coding the form. It’s also very easy to adjust should changed policies require form updates.

After converting the Summer Session Appointment form to the new software, we moved it to production server and tested the form with end users. Our first test was with the Chemistry Department Chair who completed the form for 3 summer teaching hires. I did process testing as he completed the form so I had him say aloud what he was thinking as he completed the form. He found the form straight forward to complete and easy to move on to the next person. The faculty being hired were able to view, approve, and send the form along its workflow path. We experienced a glitch with one form when the Assistant Dean opened it on his Macintosh. After closing the form and reopening it, it worked fine. Since the form was initiated on a Macintosh and two of the three faculty also used Macintoshes for their approvals and experienced no problems, we do not think the glitch was Macintosh related.

 After this initial success, we refined the form to include not only buttons for approving and rejecting and also for returning the form for further information and for canceling the form altogether. We customized the automatic email message approvers receive to let them know they have a task awaiting and created automatic email messages that are sent when a form is returned, rejected, and, of course, completed and approved. In the first two instances, the email goes to the form initiator. In the later instance, all in the approval process receive the email.

We are now doing the final testing on all the email responses. On Monday, we will begin training the 150 staff members who were using the software we replaced. We are looking forward to hearing their comments and seeing their reactions.

In order for approvers to electronically sign a digital form, we needed to collect their signatures. To do this we acquired a tablet PC and Topaz SigPlus signature software. One of the E-forms Team members wrote a statement that we show to all forms users so they know exactly how their digital signatures will be used. Then, for our pilot test, another team member went to the offices of those who would be testing the form and gathered their signatures. These signatures were saved in .jpg format, resized, sharpened, and added to the BP Logix server. When the “Approve” button is clicked on a form, the digital signature is added to the form and the next approver can see the signatures of the previous approvers.

UW-Eau Claire forms conversion project—more on the forms design process

As it turns out, creating and testing the form is the easy part. The difficult part is assuring that we have all the right fields to cover all uses and special circumstances that arise during the completion of any given form. Here’s how we decided to go about that. We met first with the “owner” of the form, that is, a representative from the department that originates the form and takes action on the form when it is completed. I’ll use our Summer Session Appointment form as an example. Faculty and instructional academic staff receive separate contracts for summer teaching. Our Human Resources Office created the Summer Session Appointment form and, after it has been completed and has the appropriate signatures, HR can issue the contract, enter the payroll information, etc. So the form begins and ends with HR. The initial information is generally added to the form in one of the academic departments by the department chair or his/her assistant. The path it then takes differs from college to college. Therefore, as we moved this form to its electronic format, we identified key stakeholders in each of the colleges who could review our electronic draft and provide information on their college’s use of that form and its workflow. We gathered all this information, edited the form, and met again with the HR representation who suggested a few more changes. We are now in the process of creating the workflow for the Summer Session Appointment form and testing it internally. We have also identified a department who is willing to pilot the form before we release it in its final form. We have tentatively (and optimistically?) scheduled training for that department on Thursday of this week. In the next entry, I’ll address our process for obtaining and digitizing the signatures of the people involved in the approving the form.