Work - Examples

The following paragraphs briefly describe a few examples of my work, and provide a link to the document itself.  These are samples of literally thousands of pages of documentation of various types that I have authored.  I am also skilled in diagraming methods, e.g. for process diagrams, as well as software processes, using Visio and an enterprise-level tool named Enterprise Architect (EA).  One of my EA diagrams at American Homes 4 Rent is used as a training aid.  I learned the value of writing - and thinking - out work before starting to develop something.  Like drawings before building a house, the document not only help me and others think it through in detail, but communicates to others what is to be done, and how to test and accept the work.

·       Tax Data Workbench - Functionality & Process Flows - documentation I wrote for the Tax Data Workbench - which had not worked correctly even after nearly 3 years of work, but I succeeded in getting it to work.  I wrote, then used this document as a way of getting at the details and understanding its complex processes, such as a SQL job with 21 stored procedures.  It illustrates my ability to generate really detailed technical documentation that is readable by non-technical people.  The bulk of it took me about 8 weeks, including analysis time to write, with updates following as I found I needed to include other specifics.  This is the complete document to provide a sense of the scope of the work.  Link

·      Variance  Reporting - this is a reporting tool with a permanent data base that provides for accumulation of variance data over time for trend analysis, with a unique user-driven mapping tool.  Generated for the Accounting team at American Homes 4 Rent.  Shows my documentation and design style.  There are four documents that specify how it is to be built and will work.  These were developed with close collaboration with the business and the SSRS developer who was to build it, providing a 2-way agreement on exactly what is to be delivered and that it will definitely meet the requirements of the business people who will use it.  I have found this method to prevent the old story of "its what we asked for but not what we need" one hears often when this method is not followed.

•      Requirements - Final - explains how the overall tool will work, the requirements it meets. Refers to detailed Excel files for structure and format specifics.  Link

•      Variance Analysis Detail Table Structure - permanent data base storing all variance details for each month; specifically designed to allow reporting tools such as Tableau or PowerBI to produce graphs of variance data over time for trend analysis. This was my suggestion that they liked and included as a requirement but which added almost no additional development cost. Link.

•      Mapping Files Formats - the "maps" are format and structure files that allow the user to generate a very customized report but without altering anything about the data itself, assuring that it will always balance to the financial statement that go into the 10K and 10Q reports for the SEC. Link.

•       Report Formats - shows how the actual reports will look when rendered in the SSRS (Microsoft SQL Server Reporting Services)reporting environment.. Link

·      GL Allocation  - Process and  Use Guide - this is a guide I wrote to enable the Accounting team members who would be using the Yardi  GL Allocation module to perform the complex, somewhat custom allocations based on cost center head counts.  It illustrates how I write and illustrate training materials.  Link.

     Enterprise System Implementation Best Practices - this is a booklet (about 50 pages) that I wrote to explain how and why all of my implementation projects were successful.  I also believe in testing at full scale before go-live.  Clue:  I learned from others.  Link.

  ·     Business Process Diagram (Visio) - this is a straight forward diagram I did for a small project with the Treasury team at American Homes 4 Rent.  At the time, the company did not "officially" use any diagraming tool.  I created this one to assist the business.  They reconcile over 210 bank accounts every day.  Link.

·      Interface Specifications - this is the design specification for the interface for sales orders in the JAFRA Indonesia project - it sent orders from the eCommerce web site to the SAP "back end" system - which handled everything else.  It featured an internal cross reference table/data base which I designed to convert various reference field codes from those used in the front end system to those required by SAP.  By using a table, rather than hard-coded translations, changes could be made  without altering any code.  Mule ESB was the interface middleware used.  Link.

·     AIMS/ERP Scheduler Specification - this is the most complex software I have ever designed.  It generates a synchronized supply chain & manufacturing schedule with backwards and forward scheduling down and up the product/project structure levels for all of a company's  products or projects of any complexity or size.  This results in a complete schedule for everything. It was coded into 11 small programs, totaling 6,000 lines of code by a team of 3 developers.  It was used for years at Alesis, which ran its global supply chain with it.  I was part of the full-scale AIMS/ERP system I designed, managed the development for and sold for 5 years.  In a technical feasibility test at a Raytheon division, it generated a full schedule for a huge road paving machine with 250,000 SKUs, thousands of subassemblies,  and a 14 level product structure - in less than 3 minutes. That was a fun moment...!  Link

.