-
Notifications
You must be signed in to change notification settings - Fork 1
Home
agcinsf edited this page Mar 19, 2015
·
7 revisions
Welcome to the purchasing wiki! This serves as both a resource for the current members of the purchasing project, as well as documentation for the future.
#Project Ideas
italics means in progress
Things to consider
For any given metric, look for differences in:
- Supplier
- Manufacturer
- Department
- Individual
- Day of week
- Week/month of year
- Product/supplier/manufacturer type
Analysis
- Classification of the spend using a heuristic or machine learning. Maybe a logistic regression to predict the likelihood of being COTS Software? We have examples of COTS software and the ongoing maintenance transactions for them. Not a lot of examples, but probably enough.
- Visualization of the processes used to buy. I suspect spend is traversing the procurement network in 10 or 20 different ways. Seeing those ways would show the scale of the problem and value of the opportunity.
- Identifying the seasonality in the spend (if any). That would help identify when the need arises (generally) for software. I would guess there is a pattern to research buys that corresponds to the academic calendar, but have no idea. Or a forecasting in general would be cool.
- Identifying (or predicting) the major places on campus (physical or departmental) where software buying takes place to identify the key markets. This would be cool as a bipartite graph showing relationships between departments on campus and software they buy. I.e. Matlab is used in Chemistry. Adobe Professional is used in Art History. Etc. Maybe using Gephi for some graph analysis? - Darius, w/ Nick
- Using text analysis and clustering/classification to assign "product types" to POs by looking through their description, supplier, etc. - Juan, w/ Kai
- Cut out the middleman (supplier). This project entails finding cases where we are buying lots of the same product from both manufacturers and suppliers. The goal is to find situations where we could purchase directly from the manufacturer and save some money by cutting out the "middle man".
Feature Creation
- Efficiency variable. Lots of features might feed into something like this, so it'll take some creative thinking, but a single measure of "efficiency" for a given department, manufacturer, etc would be very useful.
- Department size. Find external information that tells us how big a department is in faculty/staff/students/etc.
For the Berkeley campus, this information is in CalAnswers. I can try and retrieve it if anyone is interested in merging this information with the transactional data --Andrew
- Price per unit. Purchasing in bulk should yield higher prices. Fit regression models for the price per unit as a function of the total purchase size, find opportunities where we're not getting a good deal.
- Perishable. Find better purchasing practices for perishable vs. non-perishable. Maybe combine this with a seasonality analysis to see whether we should prioritize certain POs over others.
- Time to completion. This should be a marker of total cost to the university for a given PO. See if this depends on the total cost of the purchase, season, dept, etc. - Kai, with Juan
- Cost per day. Similar to "price per unit" determine if the order prices yields longer completion times.
#Data Collection
#Data Cleaning
#Data Analysis
#Data Visualization