The ABAP Detective Works the Flow (Chart)
Last month, I introduced a new path for myself in the Sequel – https://blogs.sap.com/2018/08/13/the-abap-detective-sequel/ I’ve moved to a work phase where instead of supporting an impending database platform migration (delays until happiness in testing) I’m doing an “as-built” documentation exploration coupled with proposals for enhancement to the tasks inherent to my quasi/non-governmental agency, namely a social event calendar. And maybe a tech road map.
Not an environmentally friendly way for me to do this, er, paper drawing but oh well, better to share my style than not. As I have no access to MS Visio, the tool I’d use in the past for process mapping, I went with the tool already widely used by the group, Open Office drawing. There’s probably some way to move renderings between the platforms, not to mention the business processing modeling languages popular in that channel.
I’m searching for drawing templates (read: clipart) for people/teams, for folders, and even, gasp, 3-rin binders. Arrows and call-outs are looking good or will be. SAP Workflow gods and goddesses will recognize similarities in the notation, at a base level.
The primary objective I’ve taken on is identify where there is physical paper flow that could be automated/digitized. Before recommendations come study. Sponsors, or event locations, have specific detailed data, as illustrated by a classic handwritten form from a few decades back (at most).
I notice little things like the mailing address differing from the event location and wonder what would we ask for if this planning activity started today (probably ICS file comes to mind?)
GEO: 39.312026, -76.620418 LOCATION:The Restaurant at the End of the Universe
When I think about how these activities differ from business processes is these are primarily social with a necessary administrative side. Non-profits could be businesses from tax, finance or other angles. Maybe service delivery processes is more apt.
Back to the technical database level for a bit. The sponsors, as they’re called, could be venues or vendors or clients, whatever. Keys functions are a communication research step where upcoming sessions are recorded. Of course, things change, so there’s a periodic update/refresh phase. The document printed below is a recent generation.
In the 70’s this would be called a “turnaround document”. Sent out for data collection, returned to a central office for data entry. Probably still are.
Only fields from the organization table are shown, not prior history or current events. This is used to poll by phone (as far as I know now), which leads to questions on whether email, spreadsheet exchanges or maybe even a web presence (unlikely for this side to produce but not unlikely to consume). There’s a confirmation step/process, as there should be. More on that in the future.
Another way, if I may digress a bit, of thinking about service organization flow takes me back to waste processing methodologies, essentially modelling natural decay or biological processes. I need to share the ideas as documents etc. alongside diagrams as simple as I can produce.
One critique from a predecessor in my role was the current published calendar text is ‘free form’ not lending itself to chronological sorting and other boring needs of life in the event trade.
Enter the VCAL file, or as rookie ABAP detectives call them, ICAL. The legacy data content has values such as:
Mon Jul 23 Aug 17-19
Humans pick up what this means, hopefully without a second thought. Doesn’t meet the VCALENDAR file expectations. Newer software might guess right, but for now, assume these will not compute.
So, new database table to match the old one per event/show detail. Can’t easily extend the extant data structures since a calendar invite or series thereof, due to overload of the data cells. For example, the above one row showing August 17th through the 19th would be 3 calendar entries to that one line. I’ll leave out the schema scheme parts.
My first take has minimal fields to get acceptable calendar invites, using Google and Apple devices. One of the Perl examples that got me bootstrapped is an advent calendar [ e.g. http://perladvent.org/2017/ and http://perladvent.org/2014/2014-12-18.html and of course http://perladvent.pm.org/2007/1/ ]. With minor headaches, I was able to connect these libraries to an ODBC driver (my old fave Perl DBD and DBI ) connected to a couple MS SQL databases. If you didn’t follow that last sentence at all, bear with me.
select DESCRIPTION, DTSTART, DURATION, LOCATION, concat(SUMMARY,\' : \',EventsCode) from event_calendar where EventsCode like \'H___\' order by StartDateTime
Looks odd because it’s SQL inside a Perl program. Or not so odd I imagine.
The “H” search match is one of those letters noted in the first couple flow charts above as a data classification, albeit arbitrary if not capricious. This is merely a stub/proof of concept. The working versions would join more relevant and less redundant data.
Calendar files can have a single event, or multiple. This seems directly useful for plays, say, that run through an engagement, as opposed to another opening, [of] another show.
The invite dissemination plan is another future direction to be determined; while email attachments are the norm for many, and should kind of just work, making clickable links seems straightforward enough. I’m ignoring possibly critical infra chunks like serial IDs, timezones (which had interesting experimental case failures right quick).
A more polished example snippet:
<pre> BEGIN:VCALENDAR VERSION:2.0 PRODID:SBO2.0 BEGIN:VEVENT DESCRIPTION:Cabaret DTSTART:20181021T140000 DURATION:PT3H LOCATION:806 S Broadway Baltimore MD 21231 SUMMARY:Vagabond Theatre END:VEVENT BEGIN:VEVENT ... </pre>
I chopped off the subsequent events, just to show the basic groups of data (header and detail in a sense).
Whether this work “goes to production” quickly or languishes time will tell (heh). Meanwhile I’ve learned some new wrinkles in connecting people to places where things happen, and made my life easier by knowing when I’m supposed to be somewhere.
Grateful thanks to Susan Keohan for brainstorming about flowcharts and business processes. After I had proposed this content I stumbled across a (printed and digital) document that is purportedly a GANT [sic] chart but is 100% text. More clues for the detecting process. Includes names of volunteers in the past who no longer are on board, I suspect. Hence my constant harping (okay, less constant harpy now) about “put it in the wiki not email” for the besotted hope that the wiki content will persist while emails (whether person specific or just the flash in the pan) won’t.
Moral: Keep detecting.
I found this an interesting discussion from a process flow point of view. It makes me wish that your non-profit could buy just the WF Engine, so I could help automate these flows. As a WF person, some key points (which may just be helpful) are:
Your blogs always get me thinking!
When does the process start and when does it end [?]
Hmm. I went back to the organization web page (which is always a good place to check point an internal deep dive against a public pronouncement, and I'd say a primary "deliverable" is "tickets to events." Does the process end with a ticket transaction? Not exactly, but that's probably a good enough generalization to refine the work flow diagram (and hence make improvement decisions). Measure time spent in each task, yada yada.
But there are intermediate deliverables that also merit discovery, primarily around the communication of the available events. Companies that manufacture product also have advertising staff that deliver their own independent goods/services. Think of ASUG event planning, where there are initial campaigns around calls for presentations. Then, marketing of the scheduled events after a selection flow. In the past, we used wall charts and sticky notes, then everything became magically digitally enabled and the work flow is oh so simple.
How would you indicate an "end-of-process" deliverable, whether it's a calendar or a sale (or just the satisfaction of publishing good news)?
More about your remaining points later.
(my replies, continued...)
2. Who are the agents – who would process each step, and what do you do if you can’t find them?
I believe the agents you refer to occupy the roles that I mentioned. As one example, certain volunteers are liaisons to vendors/venues. They are listed in the database as a contact person, though for more specific tacking details I'll need to research. In one "how to" document I found, specific first names or sometimes first and last names are listed ("Bob takes the draft copy to the printer", or "Sally takes the flyers to the post office"). Yeah, there should be an owner for every action, and a backup/escalation path if they go missing.
One challenge I have is those names are unfamiliar, and they could have been replaced in their roles without anyone updating the old documentation as it was unknown or trivial. I threw out the idea of swim lane diagrams I learned about in 6Sigma training (or something like that) and got some funny looks. Need to remember the audience are volunteers of a certain demographic.
3. What are the outliers – the exceptions?
That's a tough question. As a recovering DBA, I tend to write SQL that finds bad data ("US zip codes are either 5 digits, or 5+4"), except that's not what you're referring to, I assume. What could possibly go wrong? Lots, and I know enough to know I don't know the answer to that. Errors in producing labels that don't fit on a template is one that's been mentioned. I think you're looking more systemic than just grammar or typos though. Will ponder.
4. For any step, if there is only one outcome, why not automate it?
My first thought is you're over generalizing, with the idea that automation is always the answer. I've found "manual" processes that should be digital (say. collecting event details), and the technical solution is within reach, probably. But I've also found digital processes that are back-to-front or otherwise not well executed. One example is going from a free-form document to the database, rather than starting with the database then producing the document, with fewer typos and less manual work. However, besides the change and risk management involved in flipping this, there's the ownership onus so if I build it, I support it forever.
Another example is tracking event actions. As far as I know now, each event requires a phone contact (or maybe email) and a "head count" ("future 2", above). Are those singular outcomes? Perhaps. But if they were omitted, the event would still occur and patrons would probably still attend. The only reasons I'd propose taking this to digital (creating database fields, transactions, and reporting criteria) would be to (1) allow more than 1 person to track the events, (2) improve error checking to avoid missing a call, and (3) because it looks good on my resume.
The question I'd need to ask on changing this process for the better is more "are emails or web updates better than a phone call?" than "we should put these pencil marks online?". My guess would be most vendors would be fine with a quick email or poll response, thinking ahead where they're more digital natives than not. You can't minimize the quality of personal conversations, though.