What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc.
Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc.
/vijay
http://workflow.tikiwiki.org/tiki-index.php
http://www.openwfe.org
I also suggest Zimbra with aggregate portal sites (Liferay is good),
Ajax proxies, and/or RESTful web services.
Cheers,
Andre
Seen loads of the running, (Granite's Xpercom which I have used a lot in the POS industry and which is a pain, Telcordia which back then was known to be even worse...), none of them was worth a dime...
Then I saw that brilliant combination which was Comptel + Visionael, it did mass provisioning and inventory systems for a whole national DSL unbundling architecture in France. Takes some time and patience to mix/tune them together, but once done ...
Greg VILLAIN
Independant Network & Telco Architecture Consultant
+33 6 87 48 66 14
Resurrecting this thread. Anyone?
What software solution do people use for inventory management for things
like riser/conduit drawdown, fiber inventory, physical topology store,
CLR/DLR, x-connect, contracts, port inventory, etc.
Any experiences in integrating workflow into those packages for work
orders, modeling, drawdown levels, etc.
isn't it odd/lame that in many cases the answer to this is 'build your own' ?
I remember looking several years ago at a commercial fiber plant management application called Mapcom. It looked pretty good, but it was pricey, and no one wanted to spend the money on it. So... fast-forward to 2013.... and we're still using spreadsheets 
I haven't looked lately to see what's out there, but I'd imagine there *has* to be something.
I can understand why many telcos ended up building their own systems, because many of them use(d) different or home-grown provisioning/billing/plant management/trouble ticketing systems, and different back-end systems in general, making a one-size-fits-all solution tough to do.
jms
I haven't looked lately to see what's out there, but I'd imagine there *has*
to be something.
I bet this is a market/cost thing... there are ~100 people who want
this? it's going to take a few million in SWE resources to build, and
probably recovery of that expense is going to be difficult
I can understand why many telcos ended up building their own systems,
because many of them use(d) different or home-grown
provisioning/billing/plant management/trouble ticketing systems, and
different back-end systems in general, making a one-size-fits-all solution
tough to do.
this MOSTLY gets to the ins/outs formats, right? 'billing system at
$TELCO requires CSV output' (or something) and telco folk don't always
like to think about 'standards'.
I haven't looked lately to see what's out there, but I'd imagine there *has*
to be something.I bet this is a market/cost thing... there are ~100 people who want
this? it's going to take a few million in SWE resources to build, and
probably recovery of that expense is going to be difficult
True, and would explain why the systems I've seen tend to be very expensive.
I have taken a look at netdot from UOregon, and it looks like it has lots of nice features and an active development community. The main thing there is I need to really sit down and see how painful modifying the default DB schema will be to capture some of the fiber plant data I need, and preventing that all from getting blown away by the next cycle of software upgrades. Tying it into some other back-end systems we already have is another challenge that I really haven't had time to dig into yet.
I can understand why many telcos ended up building their own systems,
because many of them use(d) different or home-grown
provisioning/billing/plant management/trouble ticketing systems, and
different back-end systems in general, making a one-size-fits-all solution
tough to do.this MOSTLY gets to the ins/outs formats, right? 'billing system at
$TELCO requires CSV output' (or something) and telco folk don't always
like to think about 'standards'.
That, and there can belots of general compatibility issues. Something like:
The provisioning system is running on an old VAX mainframe, and $PROGRAM expects CSV with CR-LF, rather than just CR, but the billing system is built on a DB2 database on an IBM mainframe and doesn't know how to output the data in an acceptable format. A lot of it is probably centered around software engineering/DBA tasks, often requiring people with lots of institutional/legacy knowledge to get the appropriate pieces talking together correctly. In some cases, those people are no longer around, and consultants with the right skills (and often a pretty hefty hourly rate) need to be brought in.
I would imagine that's why some of the telcos that went on acquision binges during the dot-com boom (coughcoughworldcom 
) never fully integrated the back-end systems of those acquired telcos into their own, even though it does/did make like more painful for their customers and their own ops people. Example: "Oh wait... that's an MFS circuit. I need to get into a different system to look at that..."
jms
[snip]
See, this is a problem.... standard spreadsheet programs are such a
great competitor.
How can you possibly justify the time and expense of developing
software, if spreadsheet programs always wins against your product,
because of its low price, so that there is no net income that is
feasible to be made in that venture?
Maybe the answer is, someone did make the program... it's just
Excel, and developing more detailed custom software could be a good
idea if it provides greater utility than the applicable cost of
development -- once you have it though, maybe you don't want to
sell it because it provides a competitive edge, and noone would be
willing to pay enough for product and support anyways.... 
Off the shelf stuff? There are lots of options, but it seems like the general opinion of the IT groups I've worked with is that it's just as much work to customize and integrate them as it is to write from scratch so we tend to get further way from COTS all the time.
You should take a look at Metasolv (now part of Oracle, I believe). We used it in one of our P&L regions for some regional products for over a decade and I was always impressed by how quickly they could roll out new workflows and products in it since much of the customization work could be done by a business process architect rather than having to be coded by a developer.
We've also used Granite, which is from Telcordia, but I don't have enough direct or indirect experience to have an opinion on whether or not it's any good.
Dave
Beware of Metasolv license costs..
Beware of Metasolv in general.
In fact, I don't think it's all that odd. Ontology recapitulates phylology,
as they say, and *all* carriers are sui generis these days, excepting
possibly what's left of the RBOCs.
So it's probably not all that surprising that there's no "template" to fit
them into; the software has to be bolted on around the systems, rather than
otherwise.
Cheers,
-- jra
Unless the requirement is quite trivial, or the usage quite small..
I would question 'write everything from scratch' -- now custom code
for integrations makes sense; it doesn't make sense for every
company to become a software company though and custom code all the
bits of their systems, instead of customizing and reusing proven
code.
A solution implemented with mature OTS components doing all the heavy
lifting may be more robust, if good choices were made. Customizing
and integrating OTS components may be hard; once you do, you worry
only about maintaining customizations and integrations. Chances are
you get vendor support and well-tested software.
That is, if the integrations/customizations made are supported ones,
available through configuration of the software.
With totally custom coded software, the org bears an ongoing burden of
software reliability testing, for all the custom components. When
one finds custom software cheaper than an OTS solution... one
should probably ask... was ongoing testing, support,
updates/security patches, and maintenance included?
In other words... did the IT group just count the Initial cost to
implement, or did they actually figure out a TCO, including
changes to the custom software later required to solve scalability
issues?
The answer in some cases may be to figure out what products might fit
the need/requirement in the most general sense, and find a consulting
group adept with whichever products, rather than a local IT group.
I am sure there are plenty of inventory management and accounting type
products out in the world, able to be adapted for the unique
requirements of inventorying different kinds of things.
Chop up the problem sufficiently into bite-sized pieces, and I
believe there are bound to be existing OTS options more useful than
a spreadsheet.
Not a personal experience or recommend but I've seen Pinnacle used for this purpose.
TFA http://www.pinnsoft.com/services/operations-management.html
Infrastructure Manager allows you to track every element of your communications infrastructure, from the outside and inside cable plant to the port assignment and availability of every network provisioning device.
Just as important, Infrastructure Manager ensures that all records are immediately updated whether they are modified from inside or outside the service order and incident management process. By maintaining a single, central repository of all documentation, you'll be able to:
Establish a centralized framework for documenting your entire infrastructure
Eliminate data corruption and reduce the resources required to synchronize disparate records
Provide a unified real-time perspective on the status of all communication records
Facilitate proactive availability management for all ports and cable plant components
Enable cost-effective capacity management
Rationalize audits of your communications infrastructure
Automate updates and prevent corruption