Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Tinderbox applications >> Mapping Business Processes and Infrastructure

Message started by MJ Mastroianni on Dec 3rd, 2015, 1:39pm

Title: Mapping Business Processes and Infrastructure
Post by MJ Mastroianni on Dec 3rd, 2015, 1:39pm

Hi all,

I'm presently in the process of helping a company reorganize itself after a long period of inattention. The challenges are many, not the least of which is deciding how best to capture the existing operation in a coherent and useful way. So I'm looking for suggestions on how I might approach this with Tinderbox, as I think it may be very well suited to this complex and very multidimensional task.

Some of the central items that need to be assembled and related in useful ways include:

Many (many!) servers in various locations and for many purposes, some physical, some virtualized; physical and virtual attributes such as CPU, RAM, storage capacities and types, etc.
License details for commercial software including dev tools
A big variety of different OS's at various versions
A mixture of custom applications, commercial software, and web applications employed internally
A customer-facing website serving a variety of customers, with some features customized to individual customers
A variety of desktops with various versions of Windows
A variety of hardware peripherals
The (expected) mix of personnel responsibilities and functions
The variety of extant workflows to accomplish necessary functions, which employ the resources above in a variety of ways

So, not much to consider, really ;-)

One approach I have been considering is to just settle on a relational database scheme and use MS Access the best I can to generate various reports for working with the staff. This may be an ordered and nicely reportable approach, but it also could be quite tedious and limiting, given the very many ways various assets can be related. Much of the initial basic data is available in a set of largely unrelated spreadsheets, so import to Access is simple and normalizing the data wouldn't be too bad once a schema is chosen.

If I use Tinderbox for this task (in whole or in part), many questions arise concerning which TBX features and container structures provide the most utility to view issues from many perspectives. So I have the whole sea of potential ideas to consider to do this more effectively.

Before highlighting the oft-referenced "just get all your data into Tinderbox and let the useful structure emerge after working with it", I will just thank you in advance ;-) Yes, I understand. But I'd still like some advice on what people consider useful approaches. No doubt I'll learn much about Tinderbox in this project as details are transformed and related.

So, some of my questions concern the utility of the following:

Collecting like items together in simple obvious ways (e.g., a "Servers" container with KA's for servers, one note per server. I see that pasting spreadsheet data (with suitable column headings) makes this fairly easy

Higher levels of abstraction (e.g., a "Devices" container, with a KA of "DeviceType" perhaps, which might have values of "Server", "NAS", "Desktop", "Printer", "Scanner", "Modem", etc., etc. An "Employees" container with Employee notes? Even higher abstraction? A "Resources" container, etc., including personnel, software, hardware, etc.?

How would I best relate how various assets are employed for particular workflows? Define a workflow note for each workflow or process and link them to the associated assets? Use tags in some fashion? (I'm not familiar yet with the use of the new tags feature, btw)

Can notes which are linked in a sequential fashion all be gathered into a single agent easily? Is there much utility in using named links for various means of relating items, or does it lead to tedious manipulations?

What's the best point at which to create Prototypes? Can I import data into Prototype-assigned notes without breaking inheritance? (For example, changing the Prototype $Color and preserving the assignment of color to relevant notes, etc.)

This is a fluid and not very well defined start, so I understand that much rework and refinement will be required. But any suggestions toward useful approaches will help me get there more efficiently, I hope. I've only used Tinderbox productively as a very lightweight brainstorming or document composition tool to date, so this is a more expansive and challenging undertaking.

Finally, any tips toward making it simpler and more direct to use Tinderbox more effectively in a presentation capacity are also appreciated. I'm not sure if it's wise to use TBX live in meetings to illustrate various views of our challenges to various personnel, but I'm open to helpful suggestions if it applies and saves me a little time.

Thanks in advance for any helpful advice :)

Title: Re: Mapping Business Processes and Infrastructure
Post by Paul Atlan on Apr 2nd, 2016, 11:13pm

I've been working in Business Transformation for a some time, and every once in a while the bug bites: I'll try my hand at building a tbx file to see if something emerges. Up to now, nothing has, so I'd be very interested to know if you've managed to create something from your endeavor.

I think one of the issues is the sense of scale. Either you build a very high level map, with simple relationships, in which case visio or omnigraffle are your tools of choice, or you build detailed process lists, where excel or a process mapping tool are ideal.
Another thing: in process mapping, or infrastructure, relationships between items are very explicit: there is no hidden structure to discover, so again, a simpler mapping tool is probably ideal.

If you see this, and have delved further, I'd love to hear your thoughts.

Title: Re: Mapping Business Processes and Infrastructure
Post by MJ Mastroianni on Jun 30th, 2016, 1:00pm

Hi Paul,

I did not end up using Tinderbox extensively to use in my project, but I chalk that up to my tendency to feel uncomfortable without imposing a fair amount of structure up-front.

Once I recognized that this wasn't a very good approach (this imposition of structure too early has been discussed here many times, I'm sure), I did use Tinderbox as a kind of initial dumping ground for initial data, and that did serve me well. The nature of what I've had to do meant collecting a lot of disparate data from people according to their availabilities and capacities, which could not be done easily in a highly structured way.

As a side note, I've begun using an application called Cubetto to map processes and various more structured views, and it looks as if that will be helpful where my own deficiencies using Tinderbox keep me from using it extensively, at least right now.



Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.