Slashdot Mirror
Ask Slashdot: Management Software For Small Independent ISP?
First time accepted submitter Vorknkx writes "I work in a small ISP. Most of our customers have cable modems but some of them are using Canopy or Ubiquity products. To manage all that, we're using a number of programs and solutions not necessarily made for such a task that are kept up to date simply using copy and paste. We have an Access database for all our internet customers, an Excel document for our wireless users, The Dude to monitor every user and a custom-made web application to monitor traffic. Needless to say, we're starting to hit the limit and juggling between all these programs is a complete pain. Is there some kind of all-in-one solution that would allow us to eliminate all the copy and paste while keeping the same functionality?"
Just build yourself a LAMP setup, with workers feeding a database, and web GUI to access/update.
Sync data from other sources into that, to provide a single converged view of whatever item (customer, router, location, network link...whatever). (Don't forget copious use of memcache btw)
Trust me....this works really well and scales to millions of customers :-)
Doesn't anybody do that anymore?
“He’s not deformed, he’s just drunk!”
But you could look and see if Jet is within your budget.
http://www.obsidian.com.au/products/jet/jet-isp-telco
At the very least a base install will give you some billing software and hooks for other automation. It wouldn't hurt to drop them a line, at any rate.
disclaimer: I used to work for obsidian ~6 years ago. they're a small company, but full of bright people and they have a lot of experience in the area. if jet isn't for you i have no doubts they can at least give you some honest advice on what to look at instead that's within your budget, fits your needs.
So, you have an access database to track your Internet customers, and an Excel sheet tracking wireless customers.
Why? How did this come into being? Who thought two different solutions to essentially the same issue were a good idea? Or did no one notice? Why haven't you consolidated these (preferably in the database? Did no one know how to make that work?
I'm not trying to cast aspersions on the technical chops of people I've never met. Maybe there are really good reasons you have the solution you have. Maybe it was really the result of a series of "right decision at the time." But as an outsider, it certainly doesn't sound that way.
I'm sure there are some suggestions that could be made to integrate your existing tools better. I'm sure there are off the shelf tools that you could use.
What I'm worried about, however, is that the big problem is that have a technical capability problem, and you're trying to solve it as a tool problem. If that's not accurate, great. But I've seen company after company try to solve a "we don't have the tech skills" problem by finding "the magic tool" that will compensate. And I've rarely seen it end well.
I realize this isn't directly a response to your question. Just a suggestion before that, before you start tinkering with zoomier tools, you take a hard look at who's going to install, configure, maintain, and administer the tool, and make sure you're confident they're up to the task. If not, solve that issue first. Tools won't fix it.
OpenNMS?
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
There are commercial apps for ISPs to manage customers. When I worked for a dial-up/isdn/t1 service provide about 12 years ago, we used Platypus.
We used it both for customer service / billing and technical support. It had a windows client and a web client and used Microsoft SQL server on the backend.
Even a help desk software package could help. The great thing about Platypus is that it could handle all the credit card and billing stuff too. You might also look at HEAT or Remedy for just keeping a customer database and doing tech support.
MidnightBSD: The BSD for Everyone
I was in your position some years ago. I also know that our main operator wasted millions in Incognito software just to throw it away, and ended up paying millions to Microsoft. Obvious not the average "small ISP", but I hope you get across my point. Small/medium ISPs end up writing their own custom software, because there is not a specialized/vertical package that works as it should. I ended up doing that too, and connecting my software to a in-house developed ERP package. Check my profile in linked.in. Regards, http://pt.linkedin.com/pub/rui-ribeiro/16/ab8/434/
Depends on how big you guys really are, you say small but to me a small isp is less than 50k subscribers. If you're much smaller than this then you have more options. Anyway there aren't a lot of good drop in solutions for monitoring thousands of devices unless you're planning on spending a ton of money. Easiest way to roll a cable modem monitoring system (Note: I have personal experience doing this for ~5 million subscribers) is to build a database (MySQL/etc) and then create a collection script in perl/php/other scripting language that collects your cable modem ip addresses directly from the CMTS. Your script will log directly into the cmts execute 'show cable modem' or appropriate command for the platform your using and you will log all this information into your database. Your second script will use SNMP to collect statistics from those logged cable modem ip addresses. Things you'll want to collect would be the transmit, receive, downstream snr, upstream snr, interface statistics, etc. Once you have this information then you can put together a webpage that will present the data with nice graphs that give you a good idea of what's going on. This same script can act as a monitoring system to collect modem state changes or you can use a trap system like Nagios to just catch the alarms the CMTS can be configured to kick out. Good luck!
Nonsense. It doesn't even meet Ted Codd's original 12 rules. Postgres is the open source choice although I must admit MSSQL is really easy to set up and use (and this is is coming from an M$ hater.)
Take a look at Ubersmith. It's designed for quite a few use cases and is pretty much a complete CRM for ISPs/Telcos/Colo facilities/etc with integration into just about everything.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
Small ISP, and you dont even imagine the number of small mid companies governed on an excel sheet with the balance on cell A11 with green or red.
"I work in a small ISP."
This sums up the problems with most "Ask Slashdot" stories.
This "small" ISP could have 50 clients or 15,000.
There is no way to know.
Budgets? Staffing? Your guess is as good as mine.
Google is running hundreds of millions of customers on a MySQL Sharded Cluster. That means a hash function maps each email address onto one of 100 physical database servers. That means easy scaling.
Honestly, if you are already performing all these tasks manually and have a "working system", you would likely be better off completing your build with scripting to finish automating all the processes and completing central data storage in a database package.
... Access may slow you down.
...very important these days when clients go *poof* easily).
1) Enlarge your Access system to encompass all functionality. I've written deeper managed systems in Access (and some are still in use, LOL) which is fully capable of handling all the necessary tasks with appropriate scripting. But when you get larger
2) Graduate to MSSQL and scripted applications moving your data. There are many different ways to approach this, of course, as virtually every application builder, language and script type speaks SQL in some fashion. But the concept of centralized data storage with scripts reaching in to accomplish tasks and interfaces allowing you to manually modify the data is hardly new. The advantage of MSSQL of course is that many users can access the data instead of a single workstation. Even if you "share" the DB file in Access you don't have a true multi-user system until you can all access it at one time and make concurrent changes (a good trick in Access, but normal in MSSQL).
3) Super-Graduate to MySQL and port the entire operation to a free licensing envinroment (otherwise the same description as MSSQL! LOL). In addition to the free licensing, the programmers available in the Linux world are fairly plentiful and do not (as a rule) expect to get $30k for each application. Just remember: Don't send money to a company you cannot sue until after you have your product. Especially to a location where $500 is two year's Salary and the programmer would do better economically to disappear with that money than actually build the application! I like "one piece at a time" small script building solutions. It builds a relationship between developer and client while providing useful results with smaller amounts. And keeps the developer busy with lots of little clients (so no single client can "shut down" the developer
All the above are assuming that scripted systems can modify what needs to be modified when conditions change. Also all assume you have knowledge of at least one language or scripting language to make these changes. Generally this sort of thing is handled one item at a time, starting with the most "work-hours-intense" piece (to recoup those man-hours as quickly as possible). This is something most IT shops do for clients on a daily basis: Automation. The fact that you ARE an IT shop does not make you immune from the need to have automation! LOL
It may be more than you want... but check out Freeside.
...Steve
Why are you using access?
I suggest you get either MySQL or MSSQL to manage your contacts before you find yourself wishing you had put all that data on a real database.
The problem with your suggestion (and you are not alone in this discussion) is comparing Access, which does both application development as well as a database back end, to a pure database back end. With MySQL or MSSQL you woiuld need to add an application development platform as well.
As they already use access, it is pretty simple to move the back end to MSSQL if they need more scalability. The front end (application) can stay in Access.