RE: Inventory Tracking Software

From: Richard Henderson <richard_at_haas.berkeley.edu>
Date: Wed, 17 Oct 2007 07:13:36 -0700

The problem domain about which Hebert wrote is this: how do departments acquire functionality at the margin of central systems [while minimizing total cost to the department and the University]? The main methods are: develop custom software, borrow custom software from another department, or buy a commercial package.

 

Hebert's comments about developing pieces of functionality at the margin are a good answer for those departments that are able and willing to write custom software. Many departments cannot develop custom software, or for very good reasons do not wish to.

 

The solution center, then, is a place for such departments to get information about stock solutions to the most common problems of software functionality unmet by central systems. This information could be the name of a department that has written custom software and is willing to share it, a recommendation for a commercial package with the lowest integration costs, code or tips for the integration of commonly used commercial packages, and so on.

 

I do not envision the solution center as supporting the functionality or operation of shareware or commercial packages, only in providing information for selection and integration.

 

Organizationally, this doesn't have to be an IS&T unit or even have warm bodies - it could be a web knowledgebase operated by a campus committee.

 

But it is a way for IS&T to shape departmental behavior, if it does not like it. Behavior is chaotic in part because there is inadequate information or advice.

 

-Richard

 

-Richard

________________________________

From: Erik Klavon [mailto:erik_at_ack.berkeley.edu]
Sent: Tue 10/16/2007 3:19 PM
To: Richard Henderson
Cc: hjdiazflores_at_berkeley.edu; Jonathan Felder; E. Bond Francisco; Lois Wareham; micronet-list_at_lists.berkeley.edu
Subject: Re: [Micronet] Inventory Tracking Software

Hi Richard,

On Tue, Oct 16, 2007 at 01:55:36PM -0700, Richard Henderson wrote:
> I could have responded to Hebert's query about why we do it this way
> with yet another description of our current lack of organization, or the
> more simple response that we have no other way to do it, but I thought I
> would make a suggestion instead.
>
> Erik imputes assumptions to my suggestion: 1) that IS&T's resources are
> static, 2) that the Solution Center's scope is to solve all problems,
> and 2) that it requires creation of a massive new entity within IS&T. I
> don't subscribe to any of these.

My comments were focused on the short term (two years), in particular
the current state of flux surrounding the reorg. I am assuming during
this time resources would be roughly be what they are at present.

My hyperbole in point 2) is a reaction to the overall debate on
centralization vs. decentralization. I doubt there is a large desire
on the part of departments to shift a great deal of their internal
systems over to IST. But I feel that getting to the point where IST is
able to help departments select, implement and operate packaged
software in an advisory role will take a nontrivial amount of work. In
the short term, I'd worry about taking on a broad effort in this
area.

With regard to the second 2), I'd welcome your suggestions on how the
functions of a Solution Center could fit within the current
organization. I've made the armchair speculation that the TAM might
make sense as a home for this function. What are your thoughts?

> IS&T's resources can grow by addressing needs; substantial benefit can
> flow from addressing a few commonly shared problems;

My experience has been that the resource growth comes, if at all,
after the initial addressing of the needs and use of resources to do
so. My concern here is taking on too much in the short term.

> Solution Center might be a good alternate name/approach for some
> existing IS&T unit(s).

I won't argue with you there.

> Either there is a central source of knowledge or support about these
> needs, or there is not. Either there is a better way than ad hoc
> Micronet to solve these problems, or there is not.

I think it is worth experimenting to find out the answer to these
questions. My earlier response on this list outlines the approach I
would take (again, from an armchair point of view); try to do
something new on a small scale to see if it works. Use the results of
each success to help encourage folks to participate.

Erik

------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to
or unsubscribe from its mailing list and how to find out
about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu/

Messages you send to this mailing list are public and world-viewable,
and the list's archives can be browsed and searched on the Internet.
This means these messages can be viewed by (among others) your bosses,
prospective employers, and people who have known you in the past.
Received on Wed Oct 17 2007 - 07:26:24 PDT

This archive was generated by hypermail 2.2.0 : Wed Oct 17 2007 - 07:26:35 PDT