Open Issues and Areas to Address -- "the List"Can we get the output of PMATS changed so that, even if nothing else changes in the HW Repair process, the DTR line items for those transactions will say something useful.define precisely what DTR line item text should say for each of our transaction types.
Goals include a consistent feel, enough information to forestall some "what's this charge" questions
We're changing PMATS to put out acceptable text automatically; need to make changes in other teams  = underway ;  = waiting to go or fate is still uncertain.  = not going ahead. , establish a standard way of denoting ticket-based charges and relationship-based charges. | Item | | Type | Comments | Status
| Who
|
|---|
| 1. | PMATS code changes proposed | Tool Fix
| Proposal to sap-logistics to change the DTR text from this direct billing tool to include the RT ticket # and client name.
| Waiting transport from dev to testing; next transport 6/3/2010.
| Rob, Chris
| | 2. | Direct Billing tool prototyping | Tool Fix + Process Change
| How to adapt the TNSC billing system OIS uses to process certain kinds of transactions for CSS teams like Training, PC Service, MDS/DDM.
| Test run of Training and PC Service transactions set for night of May 25.
| Jana, Kelly, Anna, Chris, others
| | 3. | DTR Text layout standards | Process Change
| JV Uploads are still the dominant way to bill, and the client would prefer some consistency in what the DTR line item text says. We need merely conceive of some standards and adopt them the next time we make a file.
| Rules for DTR text layout agreed on in draft.
| Group | | 4. | Billing Calendar standardized | Process Change | We can improve our performance with a consistent schedule for doing billing, with goals of spreading out transactions across the month to avoid pileups at month-end. Feeds into the CSS Calendar initiative.
| Documented billing practices by group, with calendar adjustments to avoid collisions.
| Group | | 5. | Group Cohesion through a Common Perspective
| Process Change + Outreach |
- how can we get receipts emailed to everyone – who now hands out receipts and what are they like.
- should we promote a simple filemaker receipt/invoice engine to make emailable PDFs that go to them and to us
- QuickbooksOnline's invoice machine on the web? – it's free
- Do we want a BrioQuery file that prints just enough of the right stuff about a billable ticket in an attractive way to serve as a receipt-making engine?
shall we start using an email list -- css-finance@mit.edu -- instead of "to:qla,abdenna" ? It would be a mailman list that would archive mail and attachments in case it's lost or anything happens that takes Quentin out of action for a while. This encourages process transparency and protects against single-points-of-failure
| prepare CSS documentation describing our billing standards and practices, billing schedule, what our charges look like in your DTRs, who to contact for followup questions about a charge |
- Anna Pope conceived of a simple table formatted a bit like the Annual Health Plan Comparison Chart, where rows are features of the work and columns are our six or seven businesses..
- Anna Pope's idea about a chart of who we are and what we do and how we do it. This documentation would be similar to the Health Plans comparison chart from MIT benefits. We would write it.
| Consider merging the documentation component of this in with Item 10.
| Group | | 6. | Streamlining of JV Upload File Creation and Processing | Tool Fix
| Brainstorm how this could be improved for each of us that does it.
- Automation with Brioquery extracts from the warehouse?
- uniform use of custom fields that help automate billing?
- a special css-billing queue fed by web-based requests-for-payment (customized for each of out businesses) designed to feed data to the more automated JV file-creating process?
| | | | 7. | to:css-finance mailing list for processing bills,
| Process
| Would replace to:qla@mit.edu,abdenna@mit.edu with an archived mailman list. Additional hands could help with work just by being added to the list; mailings could not be lost; work could continue if Quentin was unexpectedly unavailable. Affects the DDM DB.
| List created:
css-finance@mit.edu
css-finance is more self-documenting than was css-fs.
(Css-fs is a group account for quicken online billing)
| |
| 8.
| Quickbooks expanded beyond DCAD's single-user system.
| Tool Fix
| Jeff uses QB to manage proposals and create and email invoices;
- upgrade to 2010 for Jeff (done.)
- Can we make Quickbooks multi-user enough to let the MDS SLA business operate from the same database as DCAD, including invoicing?
- Can PC Service benefit from the inventory module? from invoicing?
| Work on central server, shared access, common company files, etc., is underway.
| | | 9. | Invoices
| Tool Fix
| Our methods of creating invoices to justify and document charges is ad-hoc and often labored. Can we converge on some efficient processes or simple tools to make an emailable invoice easy to create and send?
| We're able to build invoices over the web to email using the free, best-of-breed solution from Intuit as part of its Quickbooks online package.
| | | 10. | DLC documentation of IS&T Billing
| Outreach
| Create a brief guide for the AO/FO/FA/AA community to understand IS&T billing. what we bill for, in what ways, when, how does it look in SAP DTRs when we do it, who to contact for questions
| | | | 11.
| CSS Billing Working Group Toolbox
| Tool Fix |
| do we want a collaborative environment to share tools, techniques, etc -- is our wiki page enough, or do we want any kind of shared file server for more direct |
- In what ways would Quickbooks be useful, an to whom? Should we see if MDS would find it useful for annual SLA tracking and billing, building on the work DCAD has already done? Would PC Service benefit from its inventory features? what else?
- Should we try to make available to teams the ability to bill directly for one-time charges of certain kinds, and for automatic billing of recurring charges?
- via TNSC since it exists and people use it for non-telephone charges like ACD licenses easily enough, and it can automate repeated billings; there are technical matters that might affect our desire to go this way, or we could say "here it is and you can opt in if you want – it's all good"
- Demo by Jana T and discussion with all
- do we want to recommend that someone be assigned to spend some regular time monitoring the flow of billing in the respective lines of business and wade in to help when needed, or further tune processes that need it, or what-have-you? This might be similar to Joe Doherty's role in OIS, helping the TNIS project managers deal with the paperwork from their contractors and clients, and help keep it all straight. Vendor reimbursements for repairs seems a similar problem, eg.
- how can we streamline making JV files from RT?
- Do we add consistent billing-oriented fields to RT queues that drive billing, to make producing JV files as easy as possible? This would cover VSLS and SW Repair, maybe MDS for on-call SLAs (?)
- Should there be a web-form invoice form that a team member can fill out and press send, and its billable details go somewhere and get turned into a JV by some process -- CSS Billing queue, for the moment in RT but destined to instantiate someplace else when we can do that?
| | | | 12.
| CSS HQ attention to the process
| Process Change
| Should CSS HQ take a more active role along with Finance and the TLs to understand the monthly billing, monitor the flow, step in to help if it bogs down or there's a crunch, etc.? (A role similar to this is played by Joe Doherty for TNIS in OIS.),
| It's not clear there's really a need for this, though the use of tools like the central mailing list, and quickbooks, make it all much more possible to do if it should come up again.
| |
Planning for 4/16/2010 Meeting – CSS Cohesion, Transparency, Collective Effort With Irina Vainstock facilitating, set goals for quality billing behavior and outcomes (this was identified with somewhat different words in the notes, which i liked, what were they?) If we're a cohesive group convened to make billing the best it can be, what would that be? establish css operational standards to meet those goals. Such as, set specific days in the month by which we'd have each line of business do its thing (to smooth out flow for quentin and ensure timely but consistent results for clients; decide whether to converge on JV uploads as the optimal method of transferring funds (move away from IPreqs); decide whether to offer a just-do-it billing method akin to PMATS or TNSC. 1. Schedule billing windows per line of business. Let's hammer out a consistent production schedule – how often and precisely when in the month/quarter will we commit to processing the existing billables? Goals include smoothing out volume of JV files sent to finance 2. do we all agree about now sending files to css-finance@mit.edu rather than qla,abdenna, and we'd populate css-finance with qla,abdenna and anyone else who was commissioned to help, and the material would not be lost if both anne and quentin became incapacitated in a freak accident? 3. Brainstorming on other process improvements we want to introduce to make our lives easier? - Shall we have a collective table like Anna described of who does what for whom and with what?
- Shall there be a collaborative environment in which we put process documentation, master copies of useful tools, etc? Shall it be a file server or a wiki or what?
- Should we suggest that CSS-HQ or someone apply some administrative time to helping ensure that billing is flowing smoothly in every team, and pitch in or find solutions when more intervention or extra hands are in fact called for? This would not remove operational responsibility for billing from the lines of business but rather make proper process flow an operational issue for HQ to help ensure. _Like Joe Doherty in OIS does for TNIS projects.
- What can we do about the SW Repair process's hand-built JVs -- how do we automate the generation of their JV files so Quentin doesn't have to type them out? -- TNSC?
(Identify actionable items, assign and farm out, report back.) - Can we get to a single powerful tool that creates nice JV Upload files from fields of data we have lying around the house?
- Is there value in a common client database lacking a CRM to hold it in. Is this part of what quickbooks-for-everyone would get us? Who would want to opt in to this?
- How can we get the best parts of Chuck King's system into something we can all use? What are the best parts anyhow?
- Do we add consistent billing-oriented fields to RT queues that drive billing, to make producing JV files as easy as possible? This would cover VSLS and SW Repair, maybe MDS for on-call SLAs (?)
- Should there be a web-form invoice form that a team member can fill out and press send, and its billable details go somewhere and get turned into a JV by some process -- CSS Billing queue, for the moment in RT but destined to instantiate someplace else when we can do that?
|